ini_set不能隐藏错误，仅临时修改配置；需同时设display_errors=0和error_reporting=0才能禁用错误输出，但致命错误仍会中止脚本且可能记入日志。
ini_set 不能隐藏错误，只能控制错误报告级别
ini_set 本身不“隐藏”错误，它只是临时修改 PHP 配置项。真正决定哪些错误显示或记录的，是 error_reporting 和 display_errors 这两个配置。常见误解是调用 ini_set('error_reporting', 0) 就能“让错误消失”，其实只是不让它们被报告——但致命错误（如 Fatal error）仍会中止脚本，且日志里可能照记不误。
临时关闭错误显示的正确组合
要让当前脚本运行时不输出错误信息（比如避免暴露路径、函数名等），需同时设置：
-
ini_set('display_errors', '0')：禁止错误输出到浏览器/CLI -
ini_set('error_reporting', 0)：关闭所有错误级别的报告（包括E_WARNING、E_NOTICE等）
注意：error_reporting(0) 是函数调用，比 ini_set('error_reporting', 0) 更直接可靠；两者效果一致，但前者不受 php.ini 中 error_reporting 是否为 PHP_INI_SYSTEM 级别限制（而 ini_set 对某些 INI 项无效）。
为什么有时 set_error_handler 也得配着用？
即使关了 display_errors，未捕获的异常或部分错误（如 E_USER_WARNING）仍可能触发默认错误处理器并输出内容。此时建议：
将 WCAG 2 AA 无障碍标准应用于设计系统、UI 组件和网页——通过可运行的验证器进行对比度计算，采用设计 token 模式使颜色天生可访问，设定排版和焦点状态规则，并提供语义检查清单。适用于构建或审查 UI。
立即学习“PHP免费学习笔记（深入）”；
- 提前注册空的错误处理器：
set_error_handler(function() { return true; }) - 注意：它无法捕获
Fatal error、Parse error等解析/致命错误 - 若用
register_shutdown_function捕获致命错误，记得配合error_get_last()判断是否真有错误
典型陷阱：只关 display_errors 却没动 error_reporting，结果错误虽不显示，却仍在日志里狂写，还可能拖慢性能。
生产环境该用 ini_set 吗？
不该。临时修改配置容易遗漏、难维护，且部分 INI 项（如 memory_limit）在脚本中途修改可能已无意义。更稳妥的做法是：
- 在
php.ini或.htaccess（Apache）中统一设好display_errors = Off和log_errors = On - 用
error_log()手动记录关键逻辑错误，而非依赖隐式屏蔽 - 开发时开错，上线前检查
error_reporting是否被硬编码为0—— 这会让调试变成盲操作
最常被忽略的一点：某些托管环境禁用 ini_set（disable_functions = ini_set），此时任何基于它的“隐藏”都会静默失效。务必先 var_dump(ini_set('display_errors', '0')) 看返回值是否为 false。
