用 grep -E "PHP (Fatal|Parse|Core) error|[error]" 精准匹配错误行，再用 sed -i 删除；注意日志前缀差异、macOS 兼容性、logrotate 自动化及 error_log() 无等级前缀问题。
怎样用 grep 精准提取 PHP 错误日志行
PHP 错误日志（如 error_log 或 php_errors.log）通常混杂 warning、notice、deprecated 和 fatal error，直接删整文件风险大。真正要清理的，是明确带错误等级标识的行——关键看日志开头是否含 [error]、PHP Fatal error、PHP Parse error 这类标记。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 先用
grep -E "PHP (Fatal|Parse|Core) error|\[error\]" /var/log/php_errors.log验证能否命中目标行 - 注意：Apache 的 mod_php 日志可能用
[Fri Oct 18 ...] [error]格式，Nginx + PHP-FPM 则常见ERROR: … in … on line …，需按实际日志前缀调整正则 - 如果日志启用了
log_errors_max_len截断，部分错误信息不全，此时grep可能漏匹配，建议先确认该配置值（默认 1024）
用 sed 原地删除错误行但保留其他日志
别用 rm 或清空整个文件——那会丢掉 access 日志、debug 信息甚至未触发错误的请求上下文。精准清理 = 删除特定行，而非整个文件。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 备份后再操作：
cp /var/log/php_errors.log /var/log/php_errors.log.bak - 删除含典型错误标识的行：
sed -i '/PHP \(Fatal\|Parse\|Core\) error\|\[error\]/d' /var/log/php_errors.log - 若日志含时间戳且格式统一（如
[23-Oct-2024 14:22:05 UTC]），可加锚点提升精度：sed -i '/^\[[^]]\+\] PHP Fatal error/d' /var/log/php_errors.log -
sed -i在 macOS 上不兼容 GNU 版本，需改用sed -i '' '...' file（注意空字符串参数）
用 logrotate 按错误类型自动归档+清理
手动清理治标不治本。长期运行的服务必须靠 logrotate 控制体积和敏感内容，但默认配置不区分错误级别——得自定义脚本介入。
Linux Ai Server
下载
Linux AI 服务器 — 将 Linux 服务器转换为本地 AI 推理集群。使用 systemd、NVIDIA CUDA 实现无头 Linux AI，零 GUI 开销。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
/etc/logrotate.d/php-errors中配置轮转路径（如/var/log/php_errors.log），并启用prerotate - 在
prerotate段调用过滤脚本：grep -vE "PHP (Warning|Notice|Deprecated)" /var/log/php_errors.log > /var/log/php_errors.clean && mv /var/log/php_errors.clean /var/log/php_errors.log - 注意：logrotate 默认按天/大小触发，若错误暴增，需同步调低
maxsize并加delaycompress避免压缩冲突 - 过滤后务必用
kill -USR1 $(cat /var/run/nginx.pid 2>/dev/null || echo 0)（或对应服务）重载日志句柄，否则进程还在往旧 fd 写
为什么 error_log() 输出的内容难被 grep 精准捕获
PHP 脚本里用 error_log("msg") 打的日志，默认不带任何错误等级前缀，纯文本，和 trigger_error() 或解析失败产生的标准错误格式完全不同。这类日志无法靠关键字过滤，容易误删或漏删。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 统一改用
error_log("msg", 4, "/path/to/custom.log")分离输出，避免污染主错误日志 - 若必须混写，提前约定前缀，比如
error_log("[CRITICAL] DB timeout", 0)，再用grep "\[CRITICAL\]"提取 - 检查
error_reporting设置——若关了E_ERROR，trigger_error(E_ERROR)也不会进日志，grep就永远找不到它
最易被忽略的是日志权限与 SELinux 上下文：即使 sed 命令语法全对，若 PHP 进程以 www-data 身份追加写入，而你用 root 执行 sed -i，可能导致后续日志写入失败（inode 不一致或权限覆盖）。清理前先 ls -lZ 看上下文，必要时用 chcon 恢复。
