PHP设置错误报告级别方法详解

error_reporting()需配合display_errors和log_errors才真正生效；它仅控制错误级别，不决定输出位置，且无法捕获Parse/Fatal error，后者须靠php.ini配置或register_shutdown_function兜底。

error_reporting() 函数怎么设才真正生效

直接用 error_reporting(E_ALL) 不一定能看到所有错误——它只控制 PHP 运行时的错误报告开关，不碰 display_errors 和 log_errors。常见现象是：代码里写了 error_reporting(E_ALL)，但 parse error（比如少个括号）还是不显示，因为语法解析阶段根本没走到这行。

• error_reporting() 必须放在出错代码之前，且不能被条件语句包裹（比如写在 if (DEBUG) 里却没进分支）
• 要看到 Parse error、Fatal error，得靠 php.ini 的 display_errors = On 或运行时调用 ini_set('display_errors', '1')
• 线上环境别开 display_errors，改用 log_errors = On + error_log 指定日志路径，否则敏感信息可能暴露在页面上

php.ini 里设置 error_reporting 的坑在哪

php.ini 中的 error_reporting 值必须是整数或常量名字符串（如 E_ALL & ~E_NOTICE），但实际填进去的几乎全是整数——因为 ini 文件不支持表达式计算。你写 error_reporting = E_ALL & ~E_DEPRECATED，PHP 会当成字符串处理，最终等效于 0（即关闭所有错误报告）。

• 查当前生效值：用 var_dump(error_reporting())，不是看 php.ini 里写了啥
• 安全写法是直接填整数，比如 error_reporting = 32767（对应 E_ALL 在 PHP 8.0+ 的值）
• 不同 PHP 版本 E_ALL 数值不同：PHP 7.2 是 32767，PHP 8.0+ 是 32767，但 E_STRICT 在 8.0 已废弃，硬写常量名在旧版 ini 里会报错

开发环境 vs 生产环境该设什么级别

开发时追求“宁可错报，不可漏报”，生产则相反：要静默失败，防止信息泄露。但很多人把 error_reporting(0) 当成万能开关，结果连 Fatal error 都不记录，服务挂了都不知道。

• 开发环境推荐：error_reporting(E_ALL | E_STRICT) + display_errors = On + log_errors = On
• 生产环境必须关 display_errors，但 error_reporting 至少保留 E_ERROR | E_WARNING | E_PARSE（即 255），否则 require 找不到文件、函数不存在这类致命问题就没了日志
• 注意 E_NOTICE 和 E_DEPRECATED：开发时开着能提前发现变量未定义、函数弃用；线上可关掉减少日志噪音，但别一并关掉 E_WARNING（比如 fopen 失败就是 warning，不是 notice）

为什么 set_error_handler() 拦不住 Fatal error

set_error_handler() 只捕获 E_ERROR 以下级别的错误（如 E_WARNING、E_NOTICE），对 Fatal error、Parse error、TypeError（某些情况）完全无效。这是 PHP 的底层限制，不是配置问题。

• 想兜住 Fatal error，得用 register_shutdown_function() 配合 error_get_last() 判断是否发生了未捕获的致命错误
• set_error_handler() 的回调函数里别再触发新错误（比如访问未定义数组键），否则可能造成死循环或覆盖原始错误信息
• PHP 7+ 的 TypeError 默认属于 E_ERROR 级别，但某些场景（如返回类型声明失败）会抛异常而非触发错误，这时要用 try/catch，不是 set_error_handler

真正难的不是设哪个数字，而是理解 error_reporting 控制的是“哪些错误发出来”，而 display_errors/log_errors 决定“发到哪去”——三者缺一不可，且作用阶段不同。漏掉任意一层，都会让你以为“设置了却没用”。