生产环境不能显示debug信息，因为APP_DEBUG=true会暴露代码结构、路径、数据库配置等敏感信息，给攻击者提供渗透依据；必须设为false并配置日志记录、自定义错误页、关闭响应头和PHP错误显示，再通过真实异常验证效果。
生产环境为什么不能显示 debug 信息
ThinkPHP 默认在 APP_DEBUG = true 时输出完整错误堆栈，这在开发阶段方便定位问题，但上线后等于把代码结构、路径、数据库配置甚至敏感变量直接暴露给任意访问者。真实攻击者会用 404 或非法路由反复触发异常，收集这些信息来推测框架版本、目录结构、中间件逻辑，为后续注入或反序列化攻击铺路。
核心判断：只要 APP_DEBUG = true 出现在生产环境的 .env 或 config/app.php 中，就存在高危泄露风险。
如何关闭调试但保留日志记录
关闭页面级错误显示 ≠ 关闭错误追踪。ThinkPHP 的日志系统（think\log\driver\File）默认仍会记录所有异常，只要配置得当，你既能隐藏前端报错，又能从日志里查到完整堆栈。
-
APP_DEBUG必须设为false（.env文件中写APP_DEBUG=false，注意不要加引号） -
LOG_LEVEL建议设为error,sql,notice，避免日志爆炸又不漏关键错误 - 确认
log.save_path指向非 Web 可访问目录，比如../runtime/log/，而非public/log/ - 检查
log.file_size是否设了合理上限（如2097152即 2MB），防止磁盘被撑爆
自定义 500 页面并屏蔽堆栈细节
ThinkPHP 5.1+ 默认使用 think\exception\Handle 处理异常，但它的 render() 方法在 APP_DEBUG=false 时只返回简单提示，无法满足品牌化或用户友好需求。此时需手动接管异常响应，但切忌在自定义处理中调用 var_dump($e) 或 print_r($e->getTraceAsString()) —— 这些操作会重新泄露堆栈。
立即学习“PHP免费学习笔记（深入）”；
- 在
app/exception/Handler.php的render()方法中，用$e->getMessage()获取简短错误名（如“数据库连接失败”），不要用$e->getTraceAsString() - 对用户返回统一
500.html模板，内容仅限“服务暂时不可用，请稍后再试”，不包含任何技术术语 - 如需区分错误类型做不同提示（如 404 和 500），应基于
instanceof判断异常类，而不是解析错误消息字符串 - 确保
config/exception.php中的ignore_exception不包含你关心的业务异常类，否则它们会被静默吞掉
验证是否真已隐藏堆栈（别信配置文件）
改完配置后，最常踩的坑是：缓存没清、服务器用了 opcache、或者 Nginx/Apache 把 PHP 错误兜底显示出来了。必须手动触发一次真实异常来验证。
- 临时在控制器里写一行
throw new \Exception('test debug hide');，访问对应接口，看返回是不是只有“500 错误”或自定义页面，**绝不能出现file、line、trace字样** - 检查响应头：
X-Powered-By和X-ThinkPHP是否已关闭（在config/app.php中设header_version为false） - 查看
phpinfo()页面（如有）确认display_errors = Off，且error_reporting不是E_ALL - 如果用了 CDN 或反向代理，确认它没有把源站的错误页面缓存下来（CDN 缓存状态码 5xx 很常见）
真正难的是让所有人——包括运维、测试、前端——都理解：不是“看不到错误就是没问题”，而是“看不到错误 + 日志可查 + 监控告警”才构成闭环。少一环，问题就会卡在黑盒里很久。
