error_reporting(0)仅临时屏蔽当前脚本的错误输出，不影响日志记录和执行中断；需配合ini_set('display_errors', '0')才能真正隐藏页面错误，且@运算符和set_error_handler()各有局限，不可替代二者协同。
PHP中用error_reporting()临时关闭错误显示
直接调用error_reporting(0)能立即屏蔽所有错误输出，但只影响当前脚本执行上下文，不会改变php.ini里的全局配置。它不控制错误是否被记录（log_errors仍生效），只决定是否输出到页面或终端。
常见误用是以为设了error_reporting(0)就等于“完全静默”——其实E_ERROR这类致命错误仍会中断执行，只是不显示；而E_WARNING、E_NOTICE等会被过滤掉。
- 在敏感操作前关闭：比如调用可能触发
E_WARNING的fopen()时，避免暴露路径 - 切记恢复：用
error_reporting(E_ALL & ~E_NOTICE)之类显式还原，别依赖脚本结束自动重置 - 注意作用域：函数内调用不影响外部，若需跨函数生效，得在入口或公共初始化处统一处理
配合ini_set('display_errors', '0')禁用前端输出
error_reporting()管“报什么”，ini_set('display_errors', '0')管“往哪报”。两者必须同时设置才真正实现“页面不显示错误”。单独关display_errors而保留高error_reporting级别，错误仍会写进日志（如果log_errors开着）。
典型场景是API接口返回JSON时，不能让Warning: Invalid argument...混进响应体破坏格式。
立即学习“PHP免费学习笔记（深入）”；
- 推荐组合写法：
ini_set('display_errors', '0'); error_reporting(0); - PHP 8.0+ 中
display_errors默认为'stderr'（CLI）或'0'（FPM），但不要依赖，默认值易被环境覆盖 - 该设置对已启动的输出缓冲无效——若错误发生在
ob_start()之前，仍可能冲出缓冲区
用@运算符局部抑制单条语句错误
@是运行时抑制，只对紧邻的表达式起作用，比如@file_get_contents($url)。它底层会临时把error_reporting设为0再执行，完后立刻恢复，比手动调用error_reporting()更轻量、更精准。
但它不解决根本问题，且会拖慢性能（每次都要切换错误级别），还可能掩盖真实故障。现代项目应尽量避免，仅用于兼容老旧扩展或极少数不可控I/O操作。
- 不能抑制解析错误（如语法错）、致命错误（
E_PARSE、E_COMPILE_ERROR） -
@对include/require有效，但失败时仍会返回false，需手动检查 - PHP 8.0 起，
@在严格模式下会触发E_DEPRECATED警告（虽不显示，但日志里有）
为什么不能靠set_error_handler()来“隐藏”错误
set_error_handler()是捕获并自定义处理错误，不是隐藏。它接收错误信息后，你仍要显式返回true表示“已处理，别继续报告”，否则错误照常冒泡。很多人以为设了处理器就等于关了错误，结果发现Notice还在页面上——因为没在回调里加return true;。
它适合做集中日志、异常转换（比如把E_WARNING转成RuntimeException），不适合做开关式隐错。
- 必须返回
true才能阻止默认行为（如打印到页面） - 无法捕获
E_ERROR、E_PARSE等严重错误，这些会绕过自定义处理器 - 若在处理器里抛出异常，而没配
set_exception_handler()，会导致白屏
display_errors和error_reporting的协同关系——少设一个，错误就可能意外泄露。 
