日志级别配置失效源于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/）必须存在且可写，否则缓存日志也静默失败
