error_reporting(0)仅屏蔽错误显示和报告，不阻止错误发生、脚本中断或日志记录；真正关闭日志需设置log_errors=Off。
隐错（error_reporting(0)）不是关日志，只是“装作没看见”
很多人以为把 error_reporting(0) 一设，错误就“消失”了——其实它只屏蔽了错误的**显示和报告行为**，错误本身照常发生、脚本照常中断（比如 E_ERROR），日志也照常写（只要 log_errors=On）。这就像把报警灯关掉，但火还在烧。
-
error_reporting(0)：不触发任何错误输出，也不影响error_log()或系统日志记录（前提是 PHP 配置允许日志） -
ini_set('display_errors', '0')：只管浏览器/终端是否显示，不影响日志 - 真正“关日志”的是
ini_set('log_errors', '0')，或 php.ini 中设log_errors = Off
致命错误（Fatal Error）根本绕不开日志，除非你主动禁用
E_ERROR、E_PARSE 这类错误，PHP 在终止脚本前会默认写入错误日志（如果 log_errors 开着）。哪怕你写了 error_reporting(0)，它们依然会进日志——因为 error_reporting 对 E_PARSE 无效（语法错误发生在解析阶段，代码根本没执行到那行），对 E_ERROR 也仅控制“报不报”，不控制“记不记”。
-
E_PARSE错误：只能靠修改 php.ini 的log_errors或error_log路径来干预，error_reporting()完全无效 -
E_ERROR触发时，即使error_reporting(0)，只要log_errors=On，就会写日志 - 想彻底不落日志？得同时关掉
log_errors+ 清空error_log配置（或指向/dev/null）
生产环境该怎么做：显式分离“显示”和“记录”
线上怕用户看到错误，又怕自己查不到问题——这不是靠“隐藏”解决的，而是靠精准开关。关键就是分清三件事谁管什么：
- 谁决定“要不要打印到页面”？→
display_errors - 谁决定“要不要写进文件”？→
log_errors+error_log - 谁决定“哪些级别算错误”？→
error_reporting
典型生产配置：error_reporting(E_ERROR | E_WARNING)（只报严重问题）、display_errors=Off（不暴露给用户）、log_errors=On（确保有迹可循）、error_log=/var/log/php_errors.log（集中管理）。
立即学习“PHP免费学习笔记（深入）”；
容易被忽略的坑：shutdown 函数里拿不到 parse error
有人想用 register_shutdown_function() 捕获所有错误，结果发现语法错误（E_PARSE）根本进不去——因为解析失败时，PHP 连脚本都没加载成功，更别说执行注册函数了。这类错误只能靠静态检查（如 php -l yourfile.php）或 IDE 实时提示提前发现。
而 E_ERROR 虽然能进 shutdown，但 error_get_last() 返回的类型是数组，不是 Throwable，不能用 catch 捕获，也不能用 throw new Exception() 转成异常——这是 PHP 错误模型的根本限制，不是配置能绕开的。
