日志写入失败主因是storage/logs目录权限不足、Log::driver()配置被覆盖、日志级别过严、CLI与Web路径冲突。需检查权限、驱动配置、level设置及环境路径，确保Web用户可写、驱动未被手动切换、debug级启用、CLI使用独立可写路径。
日志写入失败时先看 storage/logs 目录权限
ThinkPHP 默认把日志写到 storage/logs，但这个目录经常被忽略权限问题。Linux 下如果 Web 进程（比如 www-data 或 nginx 用户）没写入权限，日志就静默丢弃，不报错也不提示。
常见错误现象：storage/logs 目录空空如也，或者只有早期几条日志后突然中断；error_log 里看不到任何 ThinkPHP 日志相关报错。
- 用
ls -ld storage/logs看目录属主和权限，确认运行 PHP 的用户（不是当前登录用户）有写权限 - 临时测试可执行
sudo chown -R www-data:www-data storage/logs（Debian/Ubuntu）或sudo chown -R nginx:nginx storage/logs（CentOS） - 生产环境别长期用
777，最小权限原则：目录755、文件644，且属组需包含 Web 用户
Log::driver() 配置被覆盖或未生效
ThinkPHP 支持多驱动（file、socket、syslog 等），但很多人只改了 config/log.php，却在中间件、命令行或单元测试中手动调用了 Log::driver('socket')，导致后续日志走错通道，甚至直接丢弃。
使用场景：API 接口返回异常但日志没记录；Console 命令能打日志，Web 请求却不能。
立即学习“PHP免费学习笔记（深入）”；
- 检查是否在
app/common.php、中间件或控制器里显式调用了Log::driver() - 确认
config/log.php中的default值与实际需要一致，例如'default' => 'file' - Socket 驱动依赖
log-server进程，若服务未启动，日志会直接丢失，无 fallback 机制
日志级别设置过严导致关键信息被过滤
ThinkPHP 默认只记录 error 及以上级别（error、critical、alert、emergency），而开发者常习惯用 Log::info() 或 Log::debug() 调试，结果日志完全不出现。
性能影响：开启 debug 级别会显著增加 I/O，尤其高并发下可能拖慢响应，但排查期值得开。
- 检查
config/log.php中的level配置，开发期建议设为'level' => 'debug' -
Log::record()是底层写入入口，它受level控制，低于阈值的日志连磁盘 IO 都不会触发 - 注意环境变量
APP_DEBUG不影响日志级别，它只控制错误页面展示，和日志写入无关
CLI 和 Web 请求共用同一日志配置但路径冲突
ThinkPHP 在 CLI 模式下默认仍尝试写入 storage/logs，但如果部署时用的是容器或无写权限环境（比如某些 Serverless 平台），CLI 命令一跑，Log::info() 就无声失败——因为路径不可写，又没配 fallback。
兼容性影响：本地开发一切正常，上线后定时任务日志全丢，查不到执行痕迹。
- 在
config/log.php中区分环境，例如 CLI 下改用'path' => '/tmp/thinkphp-log/' - 确保目标路径存在且可写，CLI 模式下 Web 用户可能不是运行者，得用
posix_getuid()查实际 UID - 避免在
think run或队列 worker 中复用 Web 的日志句柄，进程常驻时文件句柄可能被锁死或缓存未 flush
最麻烦的其实是日志驱动初始化时机早于权限校验，出错时既不抛异常也不 warn，只能靠人工逐层确认路径、权限、级别、驱动实例状态——漏掉任意一环，日志就消失得干干净净。
