PHP生产环境必须关闭display_errors=Off并启用log_errors=On，错误仍记录到日志；禁用ini_set覆盖，优先通过php.ini或框架配置（如Laravel的APP_DEBUG）控制，同时清理CDN缓存以防暴露旧错误。
PHP 页面直接报错：display_errors 开着就藏不住
PHP 默认可能把错误直接打在网页上，比如 Parse error 或 Undefined variable，这在生产环境极其危险——暴露路径、函数名、甚至数据库结构。关掉它最直接的办法是改 php.ini 里的 display_errors，设为 Off。
但注意：这个配置是 PHP 启动时读取的，改完要重启 Web 服务（如 Apache 或 PHP-FPM）才生效；如果用的是共享主机没权限改 php.ini，就得靠代码或 .htaccess 临时干预。
-
display_errors = Off是全局开关，关掉后错误不会显示在页面，但依然会记录到日志（只要log_errors = On） - 别在代码里用
ini_set('display_errors', '0')来覆盖——它在某些 SAPI（比如 CLI）下有效，但在 Web 环境中可能被 php.ini 的system级设置锁死（看phpinfo()里display_errors的“Local Value”和“Master Value”是否一致） - 如果用了
error_reporting(E_ALL)却还看不到报错，大概率就是display_errors被关了，而不是错误没触发
开发 vs 生产：error_reporting 和 log_errors 必须配对设
光关显示不等于关错误——错误仍会发生，只是你看不见。真正安全的做法是：开发时让错误显示+记录，生产时只记录不显示。
关键不是“关”，而是“导流”：把错误引向日志文件，而不是浏览器。
立即学习“PHP免费学习笔记（深入）”；
- 生产环境必须确保
log_errors = On，并检查error_log指向的位置是否可写（比如/var/log/php_errors.log或项目内logs/error.log） -
error_reporting控制报什么级别错误，线上建议设为E_ALL & ~E_NOTICE & ~E_DEPRECATED（排除提示类和弃用警告），避免日志被无关信息刷爆 - 别信“设成
0就彻底安静了”——那只是不报告，但致命错误（如Fatal error）仍会导致脚本中断，且不记录，排查更难
运行时动态关闭：set_error_handler 不是万能补丁
有人想用 set_error_handler 捕获所有错误再静默处理，这思路危险。它只能捕获非致命错误（E_WARNING、E_NOTICE 等），对 Fatal error、Parse error 完全无效。
而且一旦自定义 handler 写错（比如抛出异常或调用未定义函数），反而引发二次崩溃。
- 真要用，只建议在调试阶段临时加一层日志输出，不要 return 或 exit
-
register_shutdown_function可配合error_get_last()捕获最后的致命错误，但仅限脚本结束前那一瞬间，不能阻止报错发生 - 最稳妥的“运行时关闭显示”其实是 HTTP 响应头层面：在出错前加
ini_set('display_errors', '0')+error_reporting(0)，但前提是错误还没触发——这在实际请求中基本不可控
WordPress / Laravel 等框架下别乱动底层配置
框架通常自带错误处理机制，比如 Laravel 的 APP_DEBUG=false 会自动关掉 display_errors 并接管错误页；WordPress 的 WP_DEBUG 也类似。硬改 php.ini 或加 ini_set 可能和框架逻辑冲突。
例如 WordPress 在 wp-config.php 里设了 define('WP_DEBUG_DISPLAY', false)，但如果你在某个插件里又执行 ini_set('display_errors', '1')，错误就又出来了。
- 优先查框架文档确认错误控制入口，而不是直奔 PHP 底层配置
- 多环境部署时（如 Docker），用
php -d display_errors=Off启动比改 ini 文件更可控 - 最易被忽略的一点：CDN 或反向代理（如 Nginx）可能缓存了带错误信息的响应——即使 PHP 已关显示，旧错误页仍可能被用户看到，记得清 CDN 缓存
