@仅抑制E_WARNING、E_NOTICE等非致命运行时错误，不屏蔽语法错误、Fatal Error、Exception及PHP 8.0+的TypeError；它临时设错误级别为0，绕过set_error_handler，且仅作用于当前表达式。
PHP @错误控制运算符到底 suppress 什么
它只抑制运行时产生的 E_WARNING、E_NOTICE、E_USER_NOTICE 等非致命错误，**不屏蔽语法错误、Fatal error、Parse error 或 Exception**。也就是说，代码写错了（比如少个括号），加 @ 完全没用，该报错还是报错。
常见错误现象：@file_get_contents("nonexistent.txt") 看似“静默失败”，但实际返回 false；如果后续直接用这个结果做字符串操作，可能触发新的 E_WARNING（而这个新警告仍会被 @ 抑制——但逻辑已崩）。
- 只对当前表达式生效，不作用于函数内部或后续语句
- 在
display_errors = On且error_reporting包含对应级别时才“可见地”被压制 - 与
ini_set("error_reporting", 0)不同：后者是全局开关，@ 是局部手术刀（但代价是性能微损）
@ 和 set_error_handler 的关系很弱
@ 运算符会临时把当前错误报告级别设为 0，绕过用户自定义的 set_error_handler 回调——不是“拦截后交给你处理”，而是“干脆不通知你”。这意味着：你在 set_error_handler 里做的日志、上报、降级逻辑，对带 @ 的表达式全部失效。
使用场景：老项目对接不可控外部资源（如某段 legacy API 返回格式偶尔错乱），又不想改调用链路时，临时兜底。但别用它掩盖本该校验的逻辑分支。
立即学习“PHP免费学习笔记（深入）”；
-
@不影响throw new Exception()，异常仍会冒泡 -
@对trigger_error("xxx", E_USER_ERROR)有效，因为它是错误，不是异常 - PHP 8.0+ 中，
@对TypeError等引擎抛出的错误依然无效
替代 @ 的三种更可控做法
多数时候，@ 是懒办法。真正健壮的写法是提前检查、封装异常、或用返回值契约代替静默。
- 用
is_file()+is_readable()替代@file_get_contents() - 把易错操作包进 try/catch（尤其 PHP 7+ 支持
TypeError、ParseError可捕获） - 自己封装函数，例如
safe_file_get_contents(string $path): ?string，内部做判断并返回null或抛出业务异常
性能提示：PHP 解析器对每个 @ 都要额外做一次错误掩码切换，高频循环里滥用会影响可观测性，也拖慢一点点执行。
为什么 IDE 和静态分析工具讨厌 @
PHPStan、Psalm、甚至 VS Code 的 Intelephense，在遇到 @fopen() 时，会丢失返回类型的推断依据——它不知道你压根没打算处理失败路径。结果就是后续变量类型变成 mixed，连锁导致更多 “undefined method” 提示。
更隐蔽的问题：CI 流程中若关闭了 display_errors，@ 会让本该暴露的潜在问题彻底隐身，直到上线后某个边缘 case 触发数据空指针。
- Git 历史里搜
@能快速定位“这里作者也不确定会不会出事”的代码段 - PHP-CS-Fixer 规则
no_useless_sprintf类似，no_unnecessary_control_character不管 @，但它有专用规则no_useless_silencing_operator - 真要用，至少配上注释说明“为何此处必须 suppress，且失败后果可控”
最麻烦的不是 @ 本身，而是它常出现在没人再维护的条件分支里——那个 @mysql_query() 可能还在某段废弃代码里喘气，而没人记得关掉它的错误抑制。
