CodeIgniter结构响应中错误日志记录_CodeIgniter错误响应日志管理【介绍】

苏承栈

2026-10-17 • 👁 0人浏览过

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 错误报告的双轨控制——它们各管一摊，关掉一个，另一摊照样出问题。

相关文章