应显式传参error_log($msg, 3, $path)并确保路径绝对、可写且手动加\n；file_put_contents()须加FILE_APPEND | LOCK_EX防并发错乱。
PHP 自带的 error_log() 和 file_put_contents() 能快速写日志，但直接裸用容易导致并发写入错乱、格式不统一、无法按级别过滤，甚至因权限或路径问题静默失败。
用 error_log() 写日志时为什么日志没生成？
常见原因是没配对的错误报告级别或目标路径不可写。默认情况下，error_log() 会走 PHP 的 error_log 配置（如写到 Web 服务器错误日志），而不是你期望的文件。
- 要写到指定文件，必须显式传入第二个参数
3（表示“以追加方式写入文件”），再传第三个参数为绝对路径：error_log("User login failed\n", 3, "/var/log/myapp/debug.log"); - 路径必须存在且 Web 进程（如 www-data 或 nginx 用户）有写权限；用相对路径极易失败，不要用
./logs/这类写法 - 该函数不自动加换行，务必在字符串末尾手动加
\n，否则多条日志会挤在同一行 - 它不支持日志级别（info/warn/error），所有内容一视同仁，调试时难过滤
用 file_put_contents() 追加日志为何偶尔丢数据？
因为默认不是原子写入，高并发下多个请求同时写同一文件，可能触发竞态，造成内容覆盖或截断。
- 必须加上
FILE_APPEND | LOCK_EX标志，强制追加并独占锁：file_put_contents("/var/log/myapp/access.log", date('Y-m-d H:i:s') . " - GET /home\n", FILE_APPEND | LOCK_EX); - 忽略
LOCK_EX是最常被跳过的一步，尤其在简单脚本中——本地测不出问题，上线后流量一上来就丢日志 - 频繁调用
file_put_contents()开销比缓冲写大，不适合每毫秒都记一条的场景（如高频埋点） - 注意返回值：失败时返回
false，建议加简单判断，避免误以为写成功了
什么时候该自己封装一个简易日志类？
当项目里出现以下任意一种情况，就该收掉零散的 error_log() 调用了：
立即学习“PHP免费学习笔记（深入）”；
- 需要区分
debug、warning、error级别，并能开关某一级别输出 - 日志要带固定前缀，比如时间戳、请求 ID、来源文件和行号
- 不同环境（dev/staging/prod）要写到不同路径，或 dev 环境同时输出到屏幕和文件
- 开始担心日志文件太大，需要按天轮转（如
app-2024-06-15.log）
一个最小可用封装只需 20 行左右：用静态方法封装写逻辑，用 date() 拼前缀，用 debug_backtrace() 抽文件和行号（仅 dev 启用），轮转靠判断文件修改时间 + rename() 即可。不必一开始就上 Monolog。
Monolog 在 PHP 日志中到底要不要引入？
如果你的项目已用 Composer 管理依赖，且未来会对接 Slack、Elasticsearch 或 syslog，Monolog 值得引入；否则，小项目硬套 Monolog 反而增加理解成本和部署负担。
- 它的核心优势是解耦「日志内容」和「输出位置」：一条
$logger->info("DB query took 120ms")可同时发到文件、邮件、Redis，无需改业务代码 - 但要注意：默认配置下，
StreamHandler不带锁，仍需手动包装或换用RotatingFileHandler（它内部用了flock） - 别直接 new Handler，优先用官方推荐的工厂方式创建：
$handler = new RotatingFileHandler('/var/log/app.log', 0, Logger::DEBUG); - 大量短生命周期脚本（如 CLI cron）中，每次 new Logger + handler 开销明显，应复用实例或改用无对象模式
真正容易被忽略的是日志内容本身：记录变量时别直接 print_r($data)，要用 json_encode($data, JSON_UNESCAPED_UNICODE) 保证可读性和兼容性；敏感字段（密码、token）必须脱敏后再进日志——这比选什么库重要得多。
