error_reporting仅控制错误报告级别，不控制显示或记录；display_errors和log_errors才分别决定错误是否输出到页面和是否写入日志。
error_reporting 不能隐藏错误通知，只能控制报告级别
很多人以为 error_reporting 能“隐藏”错误提示，其实它只决定哪些错误类型被触发（比如 E_WARNING 是否进入错误处理流程），**不控制是否显示或记录**。真正决定“是否看到错误”的是 display_errors 和 log_errors 这两个独立配置。
常见误操作：只改 error_reporting(0) 却发现页面还是报 Notice: Undefined variable —— 那是因为 display_errors 仍为 On，错误被直接输出到浏览器了。
-
error_reporting(0)：关闭所有错误报告（不触发错误处理器，也不生成日志条目） -
display_errors = Off（php.ini 或ini_set('display_errors', '0')）：错误仍会记录，但不输出到页面 -
log_errors = On+error_log = /path/to/error.log：确保错误写入文件而非丢失
生产环境必须关掉 display_errors，别依赖 error_reporting
上线后最常踩的坑：在代码里写 error_reporting(E_ALL & ~E_NOTICE)，以为这就“过滤”了 notice，结果 display_errors 没关，用户仍能看到警告；或者更糟——用 @ 抑制错误却掩盖了真实问题。
正确做法是分层控制：
立即学习“PHP免费学习笔记（深入）”；
- php.ini 中设
display_errors = Off（全局禁显示） - 保持
log_errors = On，配合error_log指向可写文件 -
error_reporting建议设为E_ALL（尤其 PHP 8+），让所有问题进日志，便于排查 - 如需临时屏蔽某行，用
@要极其谨慎，且必须确认该处错误可预期、无副作用
运行时动态设置要注意作用域和时机
error_reporting() 是运行时函数，但它的效果受 SAPI 模式影响。例如 CLI 下生效快，而 Web 服务器（如 Apache + mod_php）中，如果在脚本中途调用，可能部分错误已按旧设置触发完毕。
更关键的是：它**不会覆盖 php.ini 中已禁止的错误类型**。比如 php.ini 设了 error_reporting = E_ERROR，你在脚本开头写 error_reporting(E_ALL)，某些 SAPI（特别是 CGI/FastCGI）可能仍只报 E_ERROR。
- 最佳实践：在入口文件（如
index.php）第一行就调用error_reporting() - 避免在函数内或条件分支里反复修改，易导致日志断续或漏记
- 用
ini_get('display_errors')和error_reporting()双重检查当前实际值，别只信自己写的那行
想“过滤”特定错误？别动 error_reporting，改错误处理器
真要实现“忽略 Notice 但记录 Warning”，error_reporting 不够细粒度。PHP 的 set_error_handler() 才是正解——你可以自定义逻辑，对 $errno 做判断，再决定是否 error_log()、trigger_error() 或静默丢弃。
示例片段：
function custom_error_handler($errno, $errstr, $errfile, $errline) {
if ($errno === E_NOTICE) {
return true; // 静默忽略
}
error_log("[$errno] $errstr in $errfile:$errline");
return false; // 让系统继续处理其他错误
}
set_error_handler('custom_error_handler');
注意：set_error_handler 不捕获 E_ERROR、E_PARSE 等致命错误，它们仍会中断执行。另外，启用后 display_errors 和 log_errors 依然生效，别忘了关掉前者。
这种方案灵活，但也意味着你得自己维护错误归类逻辑和日志格式，比单纯配 ini 复杂得多——多数项目其实只需要关 display_errors + 开 log_errors 就够用了。
