APP_DEBUG=false仍泄露控制器名和模板路径，因它仅关闭调试面板而非错误出口；需手动关闭show_error_msg、禁用trace、确保Runtime可写、配置Web服务器禁止敏感目录访问。
APP_DEBUG=false 为什么还会泄露控制器名和模板路径
因为 APP_DEBUG 只控制是否显示完整堆栈和 SQL，不控制异常页面本身的渲染逻辑。ThinkPHP 默认异常处理器 \think\exception\Handle 在 APP_DEBUG=false 时仍会输出「控制器名」「模板文件路径」等上下文信息——只要没换掉这个处理器或重写 render() 方法。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 在
app/exception.php中注册自定义异常处理器，覆盖render()方法，只返回统一错误提示（如“系统繁忙”） - 确认
config/app.php中'exception_handle' => \app\exception\Handler::class指向你自己的类，而非框架默认类 - 别依赖
APP_DEBUG单一开关：它关的是“调试面板”，不是“错误出口”
show_error_msg 和 trace 配置必须手动关，不能指望 APP_DEBUG 带动
show_error_msg 是独立于 APP_DEBUG 的开关，TP5 项目默认为 true，哪怕 APP_DEBUG=false，只要它开着，500 错误仍会把堆栈吐到浏览器里。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 检查
config/app.php：确保'show_error_msg' => false - 检查
.env文件：确认没有SHOW_ERROR_MSG=true—— 它会覆盖 PHP 配置 - 禁用 trace：设
'trace' => ['status' => false]或直接'trace' => []，否则中间件可能在 HTML 注释或响应头里埋入文件列表和耗时
Runtime 目录不可写会导致“静默崩溃”，反而更难排查
关闭调试后，ThinkPHP 严重依赖 Runtime 目录生成模板缓存、路由缓存、日志（如果没关）。一旦该目录对 Web 进程不可写，请求可能卡在编译阶段，返回空白页、500 或 “页面错误!请稍后再试～”，且无任何日志可查。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- 确认
Runtime及其子目录Cache、Log、Temp对 Web 用户（如www-data、nginx）有读写权限，推荐chmod -R 775 Runtime+ 正确属组 - 上线前清空
Runtime目录内容（保留目录本身），避免残留的调试模式缓存干扰 - Docker 部署时，检查 volume 挂载是否重置了权限；可用
ls -ld Runtime确认实际属主
敏感目录被直接访问不是 ThinkPHP 的错，是 Web 服务器配置漏了
像 /application/database.php、/runtime/log/ 这类路径能被直接打开，根本原因不是框架没拦截，而是 Apache/Nginx 允许了对这些目录的 HTTP 访问。ThinkPHP 的入口只有 public/index.php，其他目录本就不该暴露。
实操建议：
立即学习“PHP免费学习笔记（深入）”；
- Apache：在项目根目录放
.htaccess，对每个敏感目录单独加Deny from all，例如：<Directory "application">Deny from all</Directory> - Nginx：在 server 块中添加 location 规则：
location ^~ /application/ { deny all; }，同理处理/config/、/runtime/、/extend/ - 别信“本地开发没问题”：PHP 内置服务器（
php -S）默认全开放，上线前必须切到真实 Web 服务器并验证
show_error_msg 被 .env 覆盖、trace 配置块留着空数组但 status 没显式关、Runtime 权限看似够却因容器挂载失效。安全不是开一个开关的事，是每一层都得亲手确认。 
