日志级别配置不当会导致ThinkPHP应用日志过少或过多。可通过五种方式调整：一、修改config/log.php中level数组；二、在.env中设置APP_ENV与APP_DEBUG联动控制；三、用apart_level为关键级别独立分流；四、运行时调用Log::init()动态重置；五、用Log::write()第三个参数true强制单条记录。
如果您在ThinkPHP应用中发现日志内容过少或过多，无法精准捕获目标问题，则很可能是日志记录级别配置不当所致。以下是设置日志记录级别的多种具体方法：
一、修改config/log.php中的全局level数组
该方式通过配置文件直接控制所有日志通道允许写入的最低级别，是生产环境最常用且推荐的配置方式。level数组中列出的级别即为被接受并写入的日志范围，未列入的级别将被静默丢弃。
1、打开项目根目录下的config/log.php文件。
2、定位到'level' => []配置项，将其修改为所需级别数组，例如仅记录错误与严重错误：'level' => ['error', 'critical']。
立即学习“PHP免费学习笔记（深入）”；
3、确保'default' => 'file'已正确设置，且channels.file.type值为'File'（大小写敏感）。
4、保存文件后执行php think clear:log清除日志缓存，避免旧缓存干扰新配置生效。
二、在.env中切换APP_ENV并联动app_debug控制调试级日志
ThinkPHP根据环境变量自动调整日志行为：开发环境（APP_ENV=development）默认启用debug/info，而生产环境（APP_ENV=production）下若app_debug=false则自动屏蔽debug和info级别，防止敏感信息泄露。
1、编辑项目根目录下的.env文件。
2、设置环境标识：APP_ENV=production。
3、显式关闭调试模式：APP_DEBUG=false。
4、确认config/log.php中'level'未包含'debug'或'info'，否则仍可能因配置覆盖导致意外输出。
5、检查runtime/log/目录权限是否为可写，否则日志写入将静默失败。
三、使用apart_level实现关键级别独立分流
该方式不改变全局level过滤逻辑，而是为特定级别（如sql、error）单独开辟物理文件，即使它们未被列入level数组，只要调试模式开启且apart_level启用，仍会写入对应文件。
1、在config/log.php的channels.file配置块内添加'apart_level' => ['error', 'sql']。
2、确保app_debug=true（仅限开发环境），因为sql级别受此开关硬性约束。
3、注意apart_level中的sql不经过level判断，但error仍需同时存在于level数组中才可写入主日志文件。
4、验证runtime/log/error/子目录是否存在且可写，否则独立错误日志将无法生成。
四、运行时动态调用Log::init()重置级别
适用于多租户、灰度发布等需按请求粒度差异化日志策略的场景。该方式绕过配置文件，在代码中实时初始化日志驱动并指定级别，优先级高于config/log.php。
1、在中间件或控制器入口处插入初始化代码：\think\Log::init(['type'=>'File','path'=>runtime_path('log/'),'level'=>['warning','error']]);。
2、确保传入的level参数为字符串数组，不可为单个字符串或空值。
3、调用前需确认runtime_path('log/')返回路径真实存在且具有写权限。
4、该操作会覆盖默认通道配置，后续所有Log::*调用均以此init参数为准，直至下次init覆盖。
五、通过Log::write()手动指定单条日志级别并强制记录
当某条关键日志必须突破当前level限制写入时，可使用write方法配合第三个参数true实现强制记录，跳过level白名单校验。
1、在业务逻辑中调用：Log::write('用户支付异常触发风控拦截', 'alert', true);。
2、注意第三个参数true为强制标志，若省略则仍受level数组约束。
3、该方式仅对当前调用生效，不改变全局配置，适合应急标记高危事件。
4、频繁使用强制写入可能导致日志泛滥，应严格限定使用范围并配合监控告警。
