FrankenPHP下kernel.response重复触发的根本原因是其HTTP/2 Server Push机制引发子请求，导致同一主请求上下文中多次执行完整内核流程；应通过$event->getRequest()->isMainRequest()在监听器开头做幂等校验，或在Caddyfile中配置php { push false }禁用推送。
FrankenPHP 下 Symfony 事件（尤其是 kernel.response）重复触发，根本原因不是事件系统本身出错，而是 FrankenPHP 的请求生命周期与传统 PHP-FPM/Swoole 不同：它默认启用「HTTP/2 Server Push」和「静态文件零拷贝响应」机制，在某些配置下会为同一请求多次调用 Symfony 内核 —— 导致 dispatch() 被执行两次甚至更多。
为什么 FrankenPHP 会多次 dispatch kernel.response？
FrankenPHP 在处理包含内联资源（如 <link rel="preload">、<script type="module">）或启用了 push 策略的响应时，会主动发起子请求预取资源。这些子请求仍走完整 Symfony HTTP 流程，但共享原始请求的会话和路由上下文，从而再次触发 kernel.request → kernel.response 链。
常见表现：
- 日志里看到同一
request_id出现两段kernel.response监听器执行记录 -
$event->getResponse()->isSent()在第二次进入监听器时为false，但实际响应早已发出 - 响应头被重复设置（如
X-Processed-By出现两次）或内容被二次 setContent() 覆盖
如何在监听器里防御重复执行？
不能依赖全局变量或静态标记（FrankenPHP 多 worker 场景下不安全），必须基于请求上下文做幂等判断。最可靠的方式是检查当前请求是否为「主请求」：
立即学习“PHP免费学习笔记（深入）”；
- 使用
$event->getRequest()->isMainRequest()—— 这是 Symfony 5.4+ 提供的明确标识，FrankenPHP 子请求返回false - 若需兼容旧版，可结合
$event->getRequest()->headers->get('Sec-Purpose') !== 'prefetch'排除 prefetch 类型子请求 - 始终前置防御：在监听器开头加
if (!$event->getRequest()->isMainRequest()) { return; } - 避免仅靠
isSent()判断：FrankenPHP 子请求的 Response 对象尚未 send，但也不应处理
配置层规避：关闭不必要的 Server Push
FrankenPHP 的 push 行为由 Caddyfile 或 frankenphp.yaml 控制，不是 Symfony 配置能干预的。必须在服务器层禁用：
- 在
Caddyfile的php指令块中显式关闭：php { push false } - 或在
frankenphp.yaml中设置：server_push: false - 若使用
frankenphp.Caddyfile模板，确认未启用push_resources或类似插件 - 禁用后，可通过
curl -I http://localhost查看响应头是否还含Link: <...>; rel=preload
调试与验证方法
不要只看日志，要抓真实请求链路：
- 在监听器里加
error_log(sprintf('[%s] %s isMain: %s', $event->getRequest()->getRequestId(), $event->getRequest()->getPathInfo(), $event->getRequest()->isMainRequest() ? 'YES' : 'NO')); - 运行
php bin/console debug:event-dispatcher kernel.response --show-private确认监听器注册无误（排除自动配置重复加载） - 用
curl -v http://localhost/your-route观察是否出现多个< HTTP/2 200块 —— 这是 FrankenPHP 多次响应的直接证据 - 临时在
public/index.php开头加error_log("INDEX.PHP LOADED: " . $_SERVER['REQUEST_URI']);，确认是否真被多次加载
真正容易被忽略的是：FrankenPHP 的子请求不会触发 kernel.terminate，也不会走 session write-close 流程，所以你在 kernel.response 里做的日志、缓存更新、CSP 注入等操作，如果没做 isMainRequest() 校验，就会静默污染主流程状态。
