log_message() 是 CodeIgniter 记录日志的唯一强制入口，需严格传入小写级别字符串和拼接好的消息，受 log_threshold 配置与日志路径权限双重管控。
log_message() 是记录错误日志的唯一入口函数
CodeIgniter 不靠 error_log() 或 trigger_error() 记录运行时问题，所有可控日志必须走 log_message()。它不是可选工具，而是框架内置日志管道的强制门禁——哪怕你手动写文件，也绕不开它对日志级别和路径的管控。
-
log_message()第一个参数是级别字符串：'error'、'debug'、'info'，不能写错大小写或拼写（比如'Error'会被静默丢弃） - 第二个参数是纯字符串消息，不支持格式化占位符（如
sprintf风格），需提前拼好：log_message('error', 'Failed to save user ID: ' . $id); - 在模型或库中调用前，确保
$this->load->library('log')已执行（CI3）；CI4 中已自动加载，但旧项目迁移时容易漏掉这步
log_threshold 配置决定日志是否落地
即使满屏调用 log_message()，若 $config['log_threshold'] 设为 0，日志就彻底消失——不是隐藏，是根本没写入磁盘。这个配置像总闸，不打开，再细的分支日志也无效。
- 开发阶段建议设为
4（记录 SQL 查询 + 所有 debug/info/error），上线后降为1或2，避免日志爆炸拖慢 I/O - 值为
1时只记'error'级别；2增加'debug'；3再加'info'；4还包含数据库查询语句 - 注意：该配置只影响
log_message()输出，PHP 原生错误（如Notice、Warning）仍由error_reporting控制，二者独立
日志路径和权限是生产环境最常卡住的点
默认日志存到 application/logs/，但这个目录在多数 Linux 生产环境没有写权限，导致日志“看起来没生成”，其实是被系统拒写了。
- 务必用绝对路径配置
$config['log_path']，例如：$config['log_path'] = '/var/www/myapp/logs/'; - 确认 Web 用户（如
www-data或nginx）对该目录有w权限，且 SELinux（如启用）未拦截写入 - 日志文件名含日期（如
log-2026-03-10.php），但文件后缀仍是.php—— 若该目录被 Web 服务器直接暴露，可能造成源码泄露，建议改后缀或移出 Web 根目录
404 和控制器缺失会自动进日志，但你不该依赖它
当请求找不到对应控制器时，CodeIgniter 自动调用 show_404() 并把事件记入日志，这看似省事，实则掩盖真实问题：比如路由写错、类名大小写不符、文件编码含 BOM，都表现为 404，但日志里只有一行“Unable to load the requested file”，没上下文。
- 这类日志级别是
'error'，受log_threshold控制，设为 0 就看不到，排查会断档 - 真正要盯的是 URI 解析链：先查
system/core/URI.php如何截取段，再看system/core/Router.php怎么匹配类/方法，最后确认文件是否存在、是否可读 - 如果日志里反复出现同一 404 路径，优先检查
.htaccess是否误重写了静态资源（如 JS/CSS），导致实际请求被转发给了 CI 路由器
log_threshold 和 PHP 错误报告的双轨控制——它们各管一摊，关掉一个，另一摊照样出问题。 
