php.ini 里关 display_errors 是最稳妥的方式
PHP 8.5 没改这个逻辑——display_errors = Off 依然是生产环境关闭错误显示的黄金标准。它不依赖代码执行，从请求一开始就不让错误冒出来，连解析错误（Parse Error）都不会显示在页面上。
- 找到你的
php.ini文件（运行php --ini或phpinfo()查路径） - 修改两行：
display_errors = Off和log_errors = On（必须开日志，否则等于“失明”） -
error_reporting建议设为E_ALL & ~E_NOTICE & ~E_DEPRECATED，既不过度啰嗦，也不漏掉关键问题 - 改完必须重启 PHP 服务（如
sudo systemctl restart php8.5-fpm或 Apache/Nginx）
常见坑：只改了 display_errors = Off 却忘了开 log_errors，结果错误既不显示也不记录，线上出问题完全没线索。
别用 @ 抑制错误来“关提示”
@ 不是关闭错误显示的手段，它只是临时吞掉某一行的运行时警告（比如 @file_get_contents()），对 Parse Error、Fatal Error 完全无效，而且 PHP 8.5 已默认在错误日志里加了抑制提示（exception.show_suppression_hint = On），会警告你“这行用了 @，建议重构”。
- 性能损耗：每次调用
@都要临时禁用错误处理器，开销比普通调用高 2–3 倍 - 掩盖问题：
@fopen('xxx')失败后你得不到任何上下文，连文件路径错不错都不知道 - PHP 8.5 中它甚至不能捕获新增的
FatalError类异常（比如调用未定义函数），误以为“安全”反而更危险
真要探测性操作，用 is_file() + is_readable() 显式判断，比 @ 干净、快、可读。
立即学习“PHP免费学习笔记（深入）”；
修复 Core bailout 状态损坏安全问题，以及 BZ2、DOM、PDO、Opcache/JIT 内存与执行错误，改进 Unicode 字素处理、URL 解析、TLS 流状态、信号分发及会话错误处理。
ini_set('display_errors', '0') 只能补救，不能兜底
如果没法改 php.ini（比如共享主机），才考虑在入口脚本顶部加这两行：
error_reporting(0);
ini_set('display_errors', '0');
但它有硬伤：
- 对脚本开头就发生的解析错误（比如语法写错了）完全无效——
ini_set根本没机会执行 - 如果项目用了 Composer 自动加载或框架早期引导逻辑，错误可能在你这行代码之前就输出了
- PHP 8.5 的新错误类型（如
JsonDecodeError）仍可能绕过该设置，因为它们本质是异常，不是传统错误
所以它只适合临时调试切换，或极简脚本；生产环境必须靠 php.ini 级控制。
PHP 8.5 新增的错误上下文，让“关显示”更不能偷懒
PHP 8.5 默认会在错误日志里自动注入请求 ID、参数快照（脱敏后）、调用栈行号范围。这意味着：一旦你关了 display_errors 却没配好 log_errors 和 error_log 路径，这些增强信息就全丢掉了。
- 检查
error_log是否指向可写路径（比如/var/log/php_errors.log），权限不对会导致日志静默失败 - 别依赖系统默认日志位置，PHP 8.5 不再保证它一定可用
-
error_reporting.trace_args = On是默认值，但若你手动设成Off，就丢掉了最关键的参数上下文
关显示不是为了让错误消失，而是把它们导流到可控、可查、带上下文的地方——这点在 PHP 8.5 里比以前更关键。
