ThinkPHP 6 默认不设置X-Content-Type-Options、X-Frame-Options、X-XSS-Protection等安全响应头，需通过全局中间件统一注入；config/app.php的response配置不生效于响应头，Nginx/CDN可能覆盖，须逐层验证。
ThinkPHP 6 默认不设置安全响应头，必须手动干预
ThinkPHP 6 默认不会自动添加 X-Content-Type-Options、X-Frame-Options、X-XSS-Protection 等安全响应头，也不会启用 Strict-Transport-Security。框架只在调试模式下加了 X-Powered-By，生产环境反而更“裸”。这不是疏忽，而是设计上把安全策略交由开发者或 Web 服务器（Nginx/Apache）统一控制——但多数人部署时直接跳过这步，导致漏洞扫描直接报中危。
在中间件里统一注入响应头最稳妥
别改核心文件，也别在每个控制器里重复写 header()。用全局中间件是最干净的方式，能覆盖所有 HTTP 响应（包括 JSON、HTML、文件下载），且不影响路由逻辑。
- 新建中间件：
app/middleware/SecurityHeaders.php - 在
handle()方法末尾调用$response->withHeader()链式设置，例如：return $response ->withHeader('X-Content-Type-Options', 'nosniff') ->withHeader('X-Frame-Options', 'DENY') ->withHeader('X-XSS-Protection', '1; mode=block'); - 注意：如果用了
Response对象的send()或output()提前终止流程，中间件会失效——确保没在控制器里手动输出并 exit - HTTPS 环境下建议加
Strict-Transport-Security，但首次部署务必用max-age=300测试，避免配置错误锁死整个域名
config/app.php 的 response 配置项不生效于安全头
config/app.php 里的 response 数组只能控制框架级行为（如默认 JSON 编码选项、模板后缀），它不接管响应头字段。你往这里塞 'headers' => ['X-Foo' => 'bar'] 是无效的——框架压根不读这个键。很多人卡在这儿反复测试却没效果，本质是误把「响应构造配置」当成「响应头配置」。
- 真正起作用的是中间件、事件监听器（
response_send）、或控制器返回前的手动withHeader() -
Response类的init()方法只初始化状态码和类型，不加载任何预设 header - 如果你用了多应用模式，中间件需注册到对应应用的
middleware.php，而非全局配置
CDN 或反向代理可能覆盖你设的响应头
Nginx、Cloudflare、阿里云全站加速等会在响应发出前重写或删除部分 header。比如 Nginx 默认会过滤掉 X-XSS-Protection，Cloudflare 免费版强制开启 X-Frame-Options: SAMEORIGIN 并禁止覆盖。
立即学习“PHP免费学习笔记（深入）”；
- 用
curl -I https://yoursite.com直连后端（绕过 CDN），确认中间件确实生效 - Nginx 中若用了
proxy_hide_header或fastcgi_hide_header，检查是否误删了你加的头 - Cloudflare 的「HTTP 严格传输安全（HSTS）」开关和你代码里的
Strict-Transport-Security会冲突，建议只留一个来源 - 某些老旧浏览器（IE9 及以下）会忽略多个
X-Frame-Options值，坚持用DENY或SAMEORIGIN单值，别写成"DENY, SAMEORIGIN"
安全头不是设了就完事，得逐层验证：代码 → Web 服务器 → CDN → 浏览器 DevTools 的 Network 标签页。漏掉任意一层，扫描工具都会亮黄灯。
