关闭 APP_DEBUG 是防止敏感信息泄露的第一步，但需同步禁用 show_error_msg、关闭 trace、确保 Runtime 目录权限正确，并排查函数名冲突、模板路径大小写、short_open_tag 等代码层问题。
关闭 APP_DEBUG 是防止敏感信息泄露的第一步，但不是全部
直接把 APP_DEBUG 设为 false（或环境变量中设 APP_DEBUG=false）确实能隐藏堆栈、SQL、文件路径等调试输出，但它只是“关掉面板”，不等于“关掉漏洞”。很多线上报错仍会暴露路径、类名、甚至数据库字段——尤其当错误处理没配好、日志没隔离、或缓存生成失败时。
-
APP_DEBUG=false后，exception_handle若仍指向\think\exception\Handle，默认异常页面可能仍显示部分上下文（如模板名、控制器名） - 未关闭
trace配置时，即使调试关闭，某些中间件或扩展仍可能在响应头或注释里埋入执行耗时、加载文件列表 - 错误页面本身若没自定义，ThinkPHP 会返回内置的“页面错误！请稍后再试～”，这个提示虽不敏感，但配合 HTTP 状态码（如 500）+ 服务指纹，容易被扫描识别技术栈
必须同步关闭 show_error_msg 和禁用 Trace 输出
ThinkPHP 的 show_error_msg 是独立开关，和 APP_DEBUG 并列生效。它控制是否向浏览器直接输出错误详情——哪怕 APP_DEBUG=false，只要 show_error_msg=true，照样吐出完整异常堆栈。
- 在
config/app.php中确认：'show_error_msg' => false（注意：TP6 默认已为false，但 TP5 及部分老项目仍默认true） - 禁用 trace：在
app.php中找到trace配置块，确保整个数组为空或显式关闭：'trace' => []或'trace' => ['status' => false] - 别只改配置文件——检查
.env是否有SHOW_ERROR_MSG=true，它会覆盖 PHP 配置
运行时目录权限和缓存失效是“静默崩溃”的主因
关闭调试后，ThinkPHP 会依赖 Runtime 目录生成编译缓存（如 common~runtime.php）、模板缓存、日志（如果没关）。一旦该目录不可写，请求会卡在缓存生成阶段，返回空白页、500 或“页面错误！请稍后再试～”，且无日志可查。
- 确保
Runtime及其子目录（Cache、Log、Temp）对 Web 服务器用户（如www、nginx、www-data）有读写权限，chmod -R 755 Runtime不够，通常需775或属组匹配 - 上线前清空
Runtime目录，避免残留的调试模式缓存干扰；但不要删Runtime本身，否则首次请求会因无法创建目录而报错 - 如果用容器部署，确认 volume 挂载时权限未被重置（Docker 中常见问题）
自定义函数/类名冲突、短标签、大小写模板路径这些“非配置项”也泄密
有些敏感信息泄露根本和 APP_DEBUG 无关，而是代码层硬伤：比如函数名撞了框架保留字、Linux 下模板路径大小写不一致、short_open_tag 关闭导致缓存文件解析失败——这些在调试模式下被掩盖，一关就炸。
立即学习“PHP免费学习笔记（深入）”；
- 检查所有自定义函数名，避开
show、error、debug、log等易与框架冲突的词（TP 曾因此报“页面错误”） - Linux 服务器上，模板调用如
$this->display('User/index')必须和实际文件名大小写完全一致；调试模式下有时会自动容错，关闭后立刻 404 或报“找不到模板” - 确认
php.ini中short_open_tag = Off时，所有缓存生成逻辑仍健壮；否则~app.php类文件可能因缺少<?php头而解析失败
真正安全的上线配置，不是单点关闭某个开关，而是让错误不落地、不回显、不生成、不残留。最常被跳过的其实是 Runtime 权限校验和 show_error_msg 的双重确认——这两个动作花不到一分钟，却能拦下 80% 的线上信息泄露事故。
