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 的底层限制，不是配置问题。
立即学习“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 决定“发到哪去”——三者缺一不可，且作用阶段不同。漏掉任意一层，都会让你以为“设置了却没用”。
