file_get_contents和file_put_contents失败不进error_log，因其静默返回false且不触发php错误处理器；必须手动检查返回值并调用error_get_last()记录日志。
直接改文件内容出错时，错误日志不会自动记录——PHP 的 file_get_contents 和 file_put_contents 不触发 PHP 错误处理器，除非你手动检查返回值并调用 trigger_error 或写入日志。
为什么 file_get_contents / file_put_contents 失败不进 error_log
这两个函数在失败时只返回 false，不抛出异常，也不触发 set_error_handler；它们属于“静默失败”型操作。PHP 默认只对语法错误、未定义变量、require 失败等触发错误报告，而 I/O 类失败需你主动判断。
- 常见失败场景：
/path/to/file不存在、目录无读/写权限、磁盘满、文件被其他进程锁定 - 即使
log_errors = On且error_log已配置，这些失败也不会自动写入日志文件 -
error_reporting(E_ALL)对这类函数无效——它们不属于 PHP 错误级别范畴
如何让替换文件失败时留下可查日志
必须显式捕获并记录。推荐在封装的替换函数中统一处理：
- 始终检查
file_get_contents返回值：若为false，立即error_log("Failed to read {$path}: " . error_get_last()['message'], 3, $log_path) - 写入前确保目录存在：
if (!is_dir(dirname($path))) { mkdir(dirname($path), 0755, true); }，否则记录 “Missing parent dir” - 使用
file_put_contents($path, $content, LOCK_EX)并检查返回字节数是否匹配预期长度，不匹配即视为写入截断，需记录警告 - 避免直接用
error_log()写文件（并发不安全），改用file_put_contents($log_path, $msg . "\n", FILE_APPEND | LOCK_EX)
容易忽略的权限与路径陷阱
Web 进程用户（如 www-data）和 CLI 用户（如 ubuntu）对同一路径可能有完全不同的权限，导致开发时正常、上线后静默失败。
-
error_log = /var/log/myapp/replace.log在 php.ini 中设置了，但 CLI 模式下该配置不生效——CLI 用的是另一份php.ini，得用php --ini确认 - 相对路径如
logs/replace.log在file_put_contents中会按当前工作目录解析（pwd输出），不可靠；一律用__DIR__ . '/logs/replace.log'或sys_get_temp_dir() . '/myapp_replace.log' - 日志目录若由 root 创建且未开放组写权限，即使
chown www-data:www-data也不够，还需chmod g+s确保新文件继承组所有权
生产环境别只靠 error_log() 记录替换失败
原生 error_log() 写文件没有锁、无轮转、无结构化字段，高并发下易丢日志或损坏内容。真正要稳，得绕过它：
- 用
file_put_contents($log_path, date('c') . " [REPLACE] {$action} failed: {$reason}\n", FILE_APPEND | LOCK_EX) - 把关键上下文一并写入：操作文件路径、
$_SERVER['REQUEST_URI']（Web）、$argv（CLI）、error_get_last() - 敏感路径（如含 token 或用户 ID）需脱敏：
preg_replace('/token=[^&]+/', 'token=***', $url) - 日志量大时，必须配
logrotate，否则单个文件几天就能撑爆磁盘——error_log配置本身不提供任何轮转能力
最常被跳过的环节是：没验证目标路径的父目录是否存在且可写，也没在每次替换前后加 clearstatcache() ——尤其在 NFS 或容器挂载卷上，缓存可能导致 is_writable() 返回过期结果。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
