PHP报错不会自动消失，需通过关闭display_errors、启用error_log记录、对关键函数加兜底判断、合理设置error_reporting级别及正确使用set_error_handler来管控。
PHP 代码报错本身不会“自动消失”，但绝大多数影响用户体验的报错，其实根本没必要让用户看见——关键在于控制错误输出位置、级别和时机。
关掉 display_errors 防止页面直接喷错
线上环境一旦开启 display_errors = On，任何 Notice、Warning 都会混在 HTML 里输出，破坏结构、暴露路径、吓到用户。
- 确认当前配置：用
ini_get('display_errors')查；用phpinfo()看完整 ini 路径 - 生产环境必须设为
Off（写在php.ini或.htaccess中：php_flag display_errors off） - 别依赖
error_reporting(0)单独关——它不拦display_errors，错照样打在页面上
用 error_log() 把错导进文件，别丢给浏览器
错误得有人看，但不是用户。把报错统一记日志，既可追溯又不干扰前端。
- 确保
log_errors = On，并设好error_log = /var/log/php_errors.log（Linux）或绝对路径（Windows） - 避免写相对路径如
./logs/error.log——CLI 和 Web 请求工作目录不同，极易写失败 - 敏感环境（如共享主机）慎用
error_log($msg, 3, $file)直接写文件，可能因权限被拒；优先走系统日志（error_log($msg, 4)）
对已知可能出错的函数加兜底，别等它崩
很多体验问题来自未捕获的运行时异常，比如 file_get_contents() 读超时、json_decode() 解析失败、mysqli_query() 返回 false。
立即学习“PHP免费学习笔记（深入）”；
-
file_get_contents()前加@不解决根本问题，反而掩盖真实原因；改用stream_context_create()设超时 + 检查返回值是否false -
json_decode($s, true)后立刻用json_last_error() === JSON_ERROR_NONE判定是否成功，别直接拿结果当数组用 - 数据库查询后，不用
if ($res)粗判，而用is_object($res) && method_exists($res, 'num_rows')或检查$mysqli->errno
开发期开 E_ALL，上线只留 E_ERROR
报错级别设太高，会淹没真正要命的问题；设太低，Undefined variable 这类隐患就悄悄进生产。
- 开发环境：用
error_reporting(E_ALL | E_STRICT)，配合 IDE 的静态分析更早发现问题 - 线上环境：至少保留
E_ERROR | E_PARSE | E_CORE_ERROR，E_WARNING和E_NOTICE建议关掉——它们通常不中断执行，但高频出现说明代码松散 - 注意：
error_reporting()不能覆盖php.ini中禁用的错误类型（如E_DEPRECATED在 PHP 8.1+ 默认关闭），得改配置文件本身
最常被忽略的一点：自定义错误处理器（set_error_handler()）若没正确返回 true，会导致错误被重复处理——一次进日志、一次打屏幕、一次触发 shutdown，三重体验打击。
