php 中 @运算符可全局抑制运行时警告和通知类错误，但无法按类型精准控制、影响性能且对致命错误无效；推荐用 error_reporting() 临时调整错误级别实现类型化忽略。
怎么用 @ 运算符忽略特定错误
PHP 的 @ 运算符能抑制单个表达式触发的错误（E_WARNING、E_NOTICE 等），但它不区分错误类型，是“全屏蔽”——只要加在函数或变量前，所有该处可能抛出的错误都会被静默丢弃。
常见错误现象：@file_get_contents("nonexistent.txt") 不报错，但你也收不到任何提示，连 false 返回值都可能被误判为正常空内容。
- 它只对运行时错误有效，对语法错误、致命错误（
E_ERROR、E_PARSE）完全无效 - 会轻微拖慢执行速度（PHP 需临时修改错误报告级别）
- 在
display_errors=On且error_reporting包含对应级别时才“可见”，否则本来就不显示 - 现代 PHP（8.0+）中，某些错误（如
TypeError）无法被@抑制
如何真正按类型忽略错误（推荐方案）
靠 set_error_handler() + error_reporting() 组合，才能做到「只忽略 E_WARNING，保留 E_NOTICE」这类精准控制。
核心思路：临时降低错误报告级别，执行操作，再恢复原设置。比 @ 更可控，也更易调试。
立即学习 “PHP 免费学习笔记（深入）”；
- 先用
error_reporting()获取当前级别，比如$old = error_reporting(E_ALL & ~E_WARNING) - 执行可能触发
E_WARNING的操作（如fopen()、parse_url()） - 立刻调用
error_reporting($old)恢复，避免影响后续代码 - 注意：不能在函数内直接写死
error_reporting(0)，否则整个脚本后续错误全没了
示例：
$old = error_reporting(error_reporting() & ~E_WARNING); $result = @parse_url("http://"); error_reporting($old); ini_set("error_reporting", ……) 为什么通常不靠谱
在运行时调用 ini_set("error_reporting", "0") 看似简单，但实际效果不稳定，尤其在 CLI 和 Web SAPI 下行为不一致。
- Web 环境中，部分 SAPI（如 Apache mod_php）会忽略运行时对
error_reporting的ini_set修改 - CLI 模式下虽可生效，但会全局影响，不是“局部忽略”
- PHP 8.0+ 已明确文档标注：
error_reporting是PHP_INI_ALL，但实际受 SAPI 限制，不保证可写 - 相比直接调用
error_reporting()函数，ini_set多一层间接，还可能被php_admin_value锁死
生产环境里最容易被忽略的一点
错误被“忽略”不等于问题消失。比如 fopen() 因权限失败返回 false，你用 @ 压住了 E_WARNING，但没检查返回值，后续 fwrite() 就会直接报 Warning: fwrite() expects parameter 1 to be resource, bool given——这个新错误反而更难定位。
真正安全的做法永远是：先判断条件是否成立（文件是否存在、目录是否可写、URL 是否合法），再操作；错误抑制只是兜底，不是替代逻辑校验的捷径。
