主流PHP框架日志需精准配置通道与触发时机：Laravel默认不捕获trigger_error()和error_log()，须调整level或统一用Log::方法；Symfony的fingers_crossed需正确配置action_level与stop_buffering；ThinkPHP的trace开关不处理异常，致命错误需手动注册shutdown函数。
PHP 主流架构（Laravel、Symfony、ThinkPHP）默认都用 Monolog 做日志底层，错误记录不是“开个开关”就完事的，关键在「日志通道配置」和「错误触发时机」是否对得上。
为什么 error_log() 和 trigger_error() 不进 Laravel 日志？
因为 Laravel 的日志系统默认只捕获 Exception 和 Error（PHP 7+ 的 Throwable），而 trigger_error() 产生的 E_USER_WARNING 等级别默认被忽略，error_log() 更是直接绕过框架日志管道。
- 解决办法：在
config/logging.php中为stack或自定义通道添加level => 'debug'，并确保monolog.level兼容E_USER_* - 更稳妥的做法是统一用
Log::warning('xxx')或report(new Exception(...))，避免混用原生函数 - 若必须拦截
trigger_error()，需手动注册set_error_handler()并转发给Log::实例
Laravel 的 log_channel 配置影响错误归类
不同环境或错误类型写到不同文件/服务，靠的是 channels 分配逻辑。比如生产环境把 critical 错误单独推送到 Sentry，而 debug 级别只写本地 storage/logs/laravel.log。
-
single通道默认只保留最近 5 个日志文件（days => 5），超期自动清理，但不会压缩 —— 大流量项目容易撑爆磁盘 -
daily通道按日期切分，但注意permission配置缺失时，Nginx/Apache 用户可能无权写入新文件 -
syslog或papertrail类通道依赖外部服务可用性，网络抖动会导致错误丢失，建议加buffer通道兜底
Symfony 的 monolog.handler.fingers_crossed 容易误配
这个 handler 的作用是「暂存日志，直到出现指定 level 的错误才真正写入」，常用来避免记录大量 info 日志却漏掉关键异常。但配置不当会完全不落盘。
立即学习“PHP免费学习笔记（深入）”；
- 常见错误：设了
action_level: error，但没配stop_buffering: true，导致后续请求的info日志持续挤占内存 - 正确做法：搭配
deduplicate和excluded_http_codes，避免重复记录 404 或健康检查请求 - 调试技巧：临时改
action_level: debug+buffer_size: 10，看是否真有日志进入缓冲区
ThinkPHP 的 log.trace 开关不等于错误捕获
'log' => ['trace' => true] 只控制是否记录 SQL 查询、路由匹配等跟踪信息，和 Exception 捕获无关。TP6 的错误处理由 think\exception\Handle 类接管，日志落地靠 Log::record() 调用。
- 默认只记录
Exception，不记录ParseError或FatalError—— 需在app/exception.php中显式注册register_shutdown_function()捕获致命错误 -
log.file路径若含变量（如runtime/log/{date}.log），注意 PHP 进程用户是否有权限创建子目录 - TP 默认关闭
display_errors，但开发环境建议打开，并配合log.level设为'debug'，否则Log::debug()不输出
真正卡住人的，往往不是“怎么记”，而是“谁在记、什么时候记、记完谁在看”。日志通道链路一环断，错误就静默消失；而分析阶段缺结构化字段（如 request_id、user_id），排查时只能靠 grep 猜。这些细节比选什么日志服务更值得花时间对齐。
