必须关闭APP_DEBUG和display_errors，否则会直接暴露服务器绝对路径、数据库表名等敏感信息；APP_DEBUG=true时框架渲染完整堆栈，display_errors=On则使PHP启动期错误及警告仍泄露路径，且FPM配置、.user.ini等可能覆盖php.ini设置，需逐层验证实际值。
必须关，不是“建议关”——APP_DEBUG=true 或 display_errors=On 任一开启，就等于把服务器路径、数据库表名、类结构甚至部分配置直接贴在响应体里给所有人看。
ThinkPHP 报错暴露绝对路径的直接原因
框架默认异常页面会渲染完整堆栈，APP_DEBUG=true 时连 /var/www/html/app/model/User.php 这种路径都原样输出。攻击者拿到这个，就能反推目录结构、猜接口、扫敏感文件（比如 .env）。
-
APP_DEBUG=false只是关掉“调试面板”，但若show_error_msg=true（TP5 默认就是 true），照样吐堆栈 - 即使关了
APP_DEBUG，PHP 层的display_errors=On仍会让Fatal error: Class 'xxx' not found这类启动期错误裸露路径 - 模板路径大小写错误（如
view/index/index.php写成View/Index/Index.php）触发的 warning，在display_errors=On下也会暴露真实路径
PHP 层 display_errors 关不干净的常见漏点
你以为改了 php.ini 就完事？错。PHP 配置有多个生效层，优先级从高到低：FPM pool > .user.ini > php.ini。FPM 配置里一句 php_admin_flag[display_errors] = on 就能把你改的 php.ini 覆盖掉。
- 用
var_dump(ini_get('display_errors'))检查实际值，别只看文件 - Nginx 下必须确认
fastcgi_intercept_errors on;已启用，并配了error_page 500 /50x.html，否则 PHP stderr 会直出 500 页面 - CLI 场景（队列、定时任务）走的是另一套 php.ini，得单独配
php -c /path/to/cli.ini
ThinkPHP 异常处理器没接管住的三种情况
自定义 exception.php 的 render() 方法再好，也救不了这三类错误：
立即学习“PHP免费学习笔记（深入）”；
- 框架加载前的致命错误：比如
require找不到核心文件、short_open_tag关了却用了标签，这类 Parse error 直接由 PHP 原生机制处理，绕过所有 ThinkPHP 中间件 - 函数名冲突：你写了
function debug()，而框架内部也有同名函数，报错时可能显示两个路径，其中一个就是框架源码路径 - Runtime 目录不可写：缓存生成失败，请求卡在
think\App::run()之前，返回空白或默认“页面错误!请稍后再试～”，但 HTTP 状态码仍是 500，配合服务指纹可被识别为 ThinkPHP
真正安全的关闭链条缺一不可
单点关闭等于没关。必须同时满足：APP_DEBUG=false + show_error_msg=false + display_errors=Off + log_errors=On + Runtime 目录权限正确 + 自定义异常模板不含 PHP 代码。其中任意一环断开，都可能让某类错误重新裸奔。
最容易被忽略的是 .env 文件是否被 Nginx/Apache 直接暴露下载，以及 Docker 容器挂载 Runtime 时 uid/gid 是否匹配 Web 服务用户。
