ThinkPHP敏感信息泄露需多层防护：必须同步关闭APP_DEBUG、show_error_msg和trace，清空Runtime/Logs并限制其Web访问，确保Runtime目录权限正确，且检查.env无覆盖配置。
ThinkPHP敏感信息泄露不是单一配置开关能解决的问题，而是调试模式、日志策略、错误处理、目录权限、代码写法等多层叠加失控的结果。最常见也最危险的泄露路径，是APP_DEBUG开启后，错误页面直接输出SQL语句、数据库连接参数、文件绝对路径、类名方法栈——这些信息足以帮攻击者快速绘制系统地图。
调试模式与错误显示必须同步关闭
仅把APP_DEBUG = false远远不够。ThinkPHP中show_error_msg是独立开关，即使调试关闭，只要它为true，异常仍会向浏览器吐出完整堆栈。需确认以下三项全部禁用：
- config/app.php 中
'app_debug' => false且'show_error_msg' => false -
'trace' => ['status' => false]或直接设为空数组'trace' => [] - 检查 .env 文件，确保没有
APP_DEBUG=true或SHOW_ERROR_MSG=true覆盖配置
日志文件是静默泄露的重灾区
日志本身不暴露在网页上，但路径可预测（如 Runtime/Logs/24_08_15.log），且默认无访问控制。一旦被直接下载，里面可能包含：
- 明文或弱加密的管理员登录凭证、API密钥
- 带参数的完整SQL查询（暴露表结构、字段名、手机号等条件值）
- Log::record() 记录的调试变量（如临时dump的用户token、session数据）
修复动作包括：关闭debug后清空Runtime/Logs目录；将日志写入非Web可访问路径（如/var/log/thinkphp/）；Nginx/Apache中禁止对Runtime目录的HTTP访问。
立即学习“PHP免费学习笔记（深入）”；
运行时目录权限和缓存机制容易被忽略
APP_DEBUG=false后，框架依赖Runtime子目录生成模板缓存、路由缓存、编译文件。若Web服务器用户（如www-data）对Runtime/Cache或Runtime/Temp无写权限，请求会失败并返回空白页或泛化错误提示——此时开发者常误判为“功能异常”，却不知真实原因是权限不足导致缓存无法生成，而错误又因show_error_msg关闭而无声消失。
- 确保 Runtime 及其子目录 Cache、Log、Temp 对Web服务用户有读写权限（推荐775，非755）
- Docker部署时检查volume挂载是否重置了属主和权限
- rm -rf Runtime/*，但保留 Runtime 目录本身
代码层硬伤同样导致泄露，与配置无关
有些敏感信息根本不会经过调试开关过滤，而是由代码行为直接输出：
- 使用
Db::query("SELECT * FROM user WHERE id = '$id'")拼接SQL，报错时MySQL原生错误会暴露表名、字段、甚至部分数据 - 模板中未过滤输出用户输入：
{$content}→ 攻击者提交<script>alert(1)</script>，不仅XSS，还可能通过JS发起跨域请求窃取其他敏感响应 - 函数名或类名冲突（如自定义
Input类撞了框架内置类），触发autoload失败，错误信息暴露物理路径
