日志级别配置失效源于level过滤、driver选择、路径权限三环节未对齐：需确认log.level设为['debug','info',...]或空数组，检查Log::driver()未被运行时覆盖为test/trace等内存驱动，并确保storage/logs及runtime目录可写。

日志级别配置失效，通常不是代码写错了，而是几个关键环节没对齐。ThinkPHP 6.0 的日志写入是“门禁式”控制：先过 level 过滤，再走 driver，最后检查路径权限。任一环卡住，Log::info() 就像没发生过一样。

确认 level 设置是否真正生效

log.level 配置只决定“哪些日志能进队列”，不是“哪些会显示在页面上”。它默认位于 config/log.php 中的 'level' => ['error'] 这类设置。

• 若设为 ['warning']，则 Log::info() 和 Log::debug() 完全不会触发写入——连磁盘 I/O 都不发起
• 开发阶段建议设为 ['debug', 'info', 'notice', 'warning', 'error']，或直接留空（level => [] 表示记录所有级别）
• APP_DEBUG => true 只影响错误页面展示，和日志 level 无关，别指望开调试模式就能看到 info 日志

检查是否被运行时代码覆盖

很多项目在中间件、命令行入口或 app/common.php 中调用了 Log::driver('socket') 或 Log::driver('test')，这会全局切换驱动，后续所有日志都走新驱动。

• 'type' => 'test' 或 'type' => 'trace' 是内存驱动，不落盘；线上误配等于关掉日志
• 全局搜索项目中所有 Log::driver( 调用，尤其注意中间件的 handle() 方法和 Console 命令的 handle()
• 确保 config/log.php 中 'default' => 'file'，且没被任何运行时逻辑覆盖

验证文件路径与用户权限是否就绪

即使 level 和 driver 都对，storage/logs 目录不可写，日志也会静默丢弃——没有报错，也不生成文件。

• 用 ls -ld storage/logs 查看属主和权限，确认运行 PHP 的用户（如 www-data 或 nginx）有写权限
• runtime/ 目录本身也必须可写，否则连日志文件都创建不了
• Docker 环境需检查挂载卷的 UID/GID 是否匹配容器内 Web 用户，chown 在宿主机执行可能无效
• CLI 模式下（如 php think hello）用户常为 root，要单独确认该用户对 storage/logs 是否可写

留意缓存与多通道配置干扰

如果你启用了缓存日志通道（比如为 cache 单独配了 logger），但没给它设好 level 或路径，也可能间接影响主日志行为判断。

• 确保 config/cache.php 中 'logger' => 'cache' 对应的通道已在 config/log.php 正确定义
• 该通道的 'level' 也要设为 ['debug', 'info'] 才能看到 hit/miss 记录
• 对应日志目录（如 runtime/log/cache/）必须存在且可写，否则缓存日志也静默失败