为什么ThinkPHP生产环境必须关闭APP_DEBUG【安全】

生产环境必须设 APP_DEBUG = false，否则错误页、SQL 日志、变量 dump 会直接暴露数据库密码、表结构、控制器路径、服务器文件系统层级——这不是“可能泄露”，而是默认行为。

举个例子：当你以为只改个配置文件就万事大吉时，ThinkPHP 可能已经在“供”你的敏感数据了。先看一幅全景图——这里梳理了调试模式开启后，框架实际上干了哪些事。

APP_DEBUG=true 时框架到底干了什么

它不是简单地“多打几行日志”，而是主动启用一整套调试基础设施：

• Trace 面板强制加载并渲染，即使你关了 SHOW_PAGE_TRACE，数据仍在内存中生成
• 异常处理器绕过你配置的 exception_handle，直走 thinkexceptionHandle 默认渲染器，输出完整堆栈
• PDO 的 debug 模式被连带激活，SQL 语句和绑定参数全量记录（哪怕数据库配置里写了 'debug' => false）
• 模板引擎禁用缓存，每次请求都重编译，同时把解析失败的原始模板路径、行号、变量名原样吐到页面上

这一套组合拳打下来，等于给攻击者送上了一份详细的地图——他们甚至不需要主动扫描，只要正常请求，就能得到你的内部结构。

为什么只改 config/app.php 不够

ThinkPHP 的 APP_DEBUG 是一个**启动前常量**，优先级链条是：入口文件 define() > .env > config/app.php。只要任一环节为 true，调试就开着。

• 入口文件（如 public/index.php）里残留 define('APP_DEBUG', true) —— 其他地方全无效
• .env 写成 APP_DEBUG="false" 或 #APP_DEBUG=false —— 引号和注释都会导致 fallback 到默认 true
• config/app.php 里写 'app_debug' => env('app_debug', true) —— 这个 env() 调用本身依赖 APP_DEBUG 是否已定义，形成逻辑闭环

也就是说，三个位置任意一个没清理干净，配置就白设了。这也是为什么有经验的老手会直接去根目录看一眼入口文件。

怎么确认它真关了

别信配置文件，看实际响应：

• 访问一个不存在的路由（如 /xyz123），curl -I 看状态码和头：HTTP/1.1 404 Not Found，且无 X-Think-Trace 头
• 故意触发 PHP 错误（如在控制器里写 foo();），页面只显示“页面错误！请稍后再试～”，不出现 Call to undefined function 堆栈
• 执行 php -r "var_dump(thinkfacadeApp::debug());"，输出必须是 bool(false)，不是 string(5) "false"

这三条验证过了，才算真正关掉了调试模式。一条不过关，都说明还有漏洞。

关掉 APP_DEBUG 只是起点，不是终点

很多人以为设了 false 就万事大吉，但以下三项不配齐，照样泄密：

• show_error_msg 在 config/app.php 中必须显式设为 false（TP5 默认 true，TP6 默认 false，老项目极易漏）
• trace 配置块不能留空或注释掉，得是 'trace' => [] 或整个删掉——ThinkPHP 会 fallback 到默认 trace 驱动
• runtime/ 目录权限不对（比如 www-data 无写权），会导致框架无法生成缓存，转而降级回“伪调试模式”，报错时连统一提示都不显示

说白了，调试模式关闭后的这三项，才是真正的“防守铁三角”。任何一项缺失，都可能让你的努力白费。