日志系统初始化需在App::init()后、路由调度前验证，执行dump(app('log') instanceof think\log\Log)输出true才正确；APP_DEBUG=true时日志被跳过，须设为false并启用File驱动；CLI环境需用绝对路径避免runtime路径错误。
确认日志系统是否已初始化
在任意控制器或中间件中插入一行代码：dump(app('log') instanceof think\log\Log);，执行后输出 bool(true) 才说明日志容器已正确加载。若为 false，说明框架尚未完成初始化——常见于在 App::init() 前调用 Log 或自定义入口未加载 config/log.php。
这一步必须放在请求生命周期的「应用初始化之后、路由调度之前」执行，比如在全局中间件的 handle() 方法里最稳妥。过早调用会得到 null 或报错，因为日志驱动依赖配置系统，而配置在 App::init() 中才真正载入。
验证日志写入是否被静默丢弃
方法一：强制触发一条 error 级别日志并立即落盘
在控制器中写：think\facade\Log::error('debug test'); think\facade\Log::save();
注意必须紧跟 save()，否则日志还在内存缓冲区，请求结束前不会写入文件。
方法二：关闭缓冲，让每次记录都实时落盘
在 config/log.php 的默认通道配置中加入 'buffer' => 0。缓冲值设为 0 表示禁用缓冲，适合调试阶段；但生产环境务必恢复为默认值（如 10），否则高频写入会拖慢接口响应。
立即学习“PHP免费学习笔记（深入）”；
【APP_DEBUG=true 时日志根本不会写入 runtime/log/】 开发者常误以为开启调试模式就能看到日志，实际上 APP_DEBUG=true 会跳过全部日志写入逻辑，错误直接渲染到页面。调试日志必须确保 .env 中为 APP_DEBUG=false，且 config/app.php 中 'log' => ['type' => 'File'] 已启用。
定位日志未生成的具体拦截点
第一步：检查通道是否存在且可访问
运行命令 php think log:channel default（需先安装 thinkphp-helper 或自定义指令），若报错 Channel [default] not exists，说明 config/log.php 中 channels.default 配置缺失或格式错误。
第二步：确认日志处理器是否被调用
在你的自定义 File 日志驱动类（如 app/common/log/CustomFileLog.php）write() 方法第一行加 file_put_contents(runtime_path() . 'log/debug_handler_called.log', date('H:i:s') . "\n", FILE_APPEND);。如果该文件始终为空，说明日志门面调用未抵达处理器——问题出在门面层或通道配置；如果该文件有内容但目标日志文件仍为空，则是 write() 内部逻辑或权限问题。
第三步：手动模拟门面调用链路
执行 php -r "var_dump((new think\log\Log())->getChannel('default')->getHandler());"。若返回 null，证明通道配置中 handler 初始化失败，大概率是 path 路径不存在或不可写；若返回对象实例，说明处理器已就位，问题聚焦在 write() 方法内部或 file_put_contents 权限。
排查 CLI 环境下日志路径失效
在定时任务中执行 php think cron:run 时，runtime_path() 返回的是 CLI 当前工作目录下的 runtime，而非 Web 服务器的 public/runtime。若 crontab 未指定 cd 切换目录，【日志会尝试写入 /root/runtime/log/ 或 /usr/bin/runtime/log/ 这类非法路径】，导致 file_put_contents 静默失败。
临时验证方式：在命令类 execute() 方法开头加 file_put_contents('/tmp/cli_cwd.txt', getcwd(), FILE_APPEND);，运行后查看该文件内容，确认实际工作目录是否为你预期的项目根目录。
永久修复方案：在 config/log.php 的通道 path 配置中使用绝对路径，例如 'path' => '/var/www/myapp/runtime/log/cron/'，而不是依赖 runtime_path() 动态拼接。
