生产环境必须设app_debug=false，否则错误页、sql日志、变量dump会直接暴露数据库密码、表结构、控制器路径和服务器文件系统层级；其优先级为入口文件define()> .env > config/app.php，任一环节为true即开启调试，需同时检查show_error_msg=false、trace配置清空及runtime目录写权限。
生产环境必须设 APP_DEBUG = false，否则错误页、SQL 日志、变量 dump 会直接暴露数据库密码、表结构、控制器路径、服务器文件系统层级——这不是“可能泄露”，而是默认行为。
APP_DEBUG=true 时框架到底干了什么
它不是简单地“多打几行日志”，而是主动启用一整套调试基础设施：
-
Trace面板强制加载并渲染，即使你关了SHOW_PAGE_TRACE，数据仍在内存中生成 - 异常处理器绕过你配置的
exception_handle，直走\think\exception\Handle默认渲染器，输出完整堆栈 - 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(\think\facade\App::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 无写权），会导致框架无法生成缓存，转而降级回“伪调试模式”，报错时连统一提示都不显示
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
