Symfony JSON 响应在 FrankenPHP 被篡改修复-php教程-PHP中文网

frankenphp会把jsonresponse变成html，因其默认启用caddy内容协商，当accept头含text/html时“降级”为html；若symfony formatlistener配置fallback_format: html或path规则不严，便会将json响应交由twig渲染，导致json被包裹进html标签中。

symfony json 响应在 frankenphp 被篡改修复

FrankenPHP 下 Symfony 的 JSON 响应被篡改（比如变成 HTML、内容被转义、或额外插入 HTML 标签），根本原因不是 Symfony 写错了，而是 FrankenPHP 的默认 MIME 类型协商机制和 Symfony 的 FormatListener 发生了冲突——前者按 Accept 头“猜格式”，后者又按路由前缀强制绑定 JSON，两边没对齐，结果响应体被框架二次渲染成模板。

为什么 FrankenPHP 会把 JsonResponse 变成 HTML？

FrankenPHP 默认启用 Caddy 的 content negotiation（内容协商），当它看到请求头里有 Accept: text/html,*/*（常见于浏览器直接访问 API 路径、或 curl 不带 -H "Accept: application/json"），就会尝试把响应“降级”为 HTML。而 Symfony 的 FormatListener 若配置了 fallback_format: html 或未严格限制 path 规则，就会接管这个请求，走 Twig 渲染流程，最终把原本的 JsonResponse 对象喂给模板引擎——于是出现 {"data":...} 被包进里的现象。

典型错误现象：Content-Type: text/html; charset=UTF-8，但响应体是合法 JSON 字符串（被当成纯文本渲染）
或更糟：响应体变成 {"error":"..."}
只发生在 FrankenPHP，Nginx+PHP-FPM 下正常 → 说明问题出在服务器层协商逻辑

禁用 FrankenPHP 的自动格式协商

FrankenPHP 没有全局开关关 content negotiation，但可以在 Caddyfile 中针对 API 路由显式关闭：

Feishu calendar sync, local ics to json data for AI agent

将ICS日历文件转为JSON格式，用于飞书日历导入导出及数据集成。

下载

handle /api/* {
    # 禁用 Caddy 自动根据 Accept 头切换格式
    header -Accept
    # 强制所有 /api/ 下请求以 application/json 处理
    header Set "Accept" "application/json"
    php
    respond * 200
}

关键点：header -Accept 移除原始 Accept 头，再用 header Set "Accept" "application/json" 注入固定值，让 Symfony 的 FormatListener 无歧义可选
不要只写 php，必须跟 respond * 200，否则 FrankenPHP 可能 fallback 到默认 HTML 渲染
若使用 worker 模式，确保该 handle 块也套在 php_server 块内，否则 PHP 执行路径不生效

Symfony 端要锁死 JSON 格式链路

光靠 FrankenPHP 层拦截不够，Symfony 自身也要切断 HTML 回退路径：

删掉 framework.yaml 中 format_listener 的 fallback_format 配置项，或明确设为 json
确保 rules 的 path 精确匹配 API 前缀，例如 ^/api(?!/admin)，避免正则过于宽泛
在控制器中，**永远优先用 JsonResponse，而非 Response + json_encode()** —— 前者自带 Content-Type: application/json，且绕过 Serializer 和 Twig 流程
检查是否误启用了 FOSRestBundle 的 view_response_listener，它会在 JsonResponse 上再套一层 View，导致重复序列化

CORS 预检请求引发的 JSON 丢失

浏览器发 OPTIONS 预检时，FrankenPHP 默认返回空响应（204），但 Symfony 若未配置异常监听器，可能 fallback 到 HTML 错误页，导致预检失败 → 后续真实请求被浏览器拦截，开发者误以为“JSON 消失了”。

验证方式：用 curl -X OPTIONS -H "Origin: https://example.com" http://localhost/api/users 看响应头是否含 Access-Control-Allow-Methods
修复：在 Caddyfile 中显式处理 OPTIONS：

handle OPTIONS /api/* {
    header Access-Control-Allow-Origin "*"
    header Access-Control-Allow-Methods "GET, POST, PUT, DELETE, OPTIONS"
    header Access-Control-Allow-Headers "Content-Type, Authorization, X-Requested-With"
    header Access-Control-Allow-Credentials "true"
    respond "" 204
}

FrankenPHP 的信任边界很清晰：它只保证“PHP 进程不被远程控制”，但不保证“PHP 输出不被上层框架误处理”。所以 JSON 被篡改从来不是 FrankenPHP 的 bug，而是两端配置没对齐的信号——修的时候，得同时盯住 Caddyfile 的请求头干预和 Symfony 的 format_listener 规则。漏掉任意一端，问题都会复现。

php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！