FrankenPHP 不解决 Symfony JSON 响应 OOM 问题，因它不改变 PHP 内存模型；需改用 StreamedResponse + Generator 流式输出，配合 ob_flush()/flush() 和手动 JSON 格式控制。
FrankenPHP 本身不接管 Symfony 的响应生成逻辑，它只是以 SAPI 形式运行 PHP，所以“超大接口返回数据”问题的根因不在 FrankenPHP，而在 Symfony 的响应构造方式。直接用 JsonResponse 或全量 json_encode() 仍会爆内存——FrankenPHP 不会 magically 解决 PHP 进程内的内存瓶颈。
为什么 FrankenPHP + Symfony 默认 JSON 响应还是会 OOM
FrankenPHP 启动的是标准 PHP-FPM 兼容模式（或 HTTP/2 Server 模式），但它不改变 PHP 执行时的内存模型。当你在控制器里写 return new JsonResponse($hugeArray)，Symfony 仍会把整个 $hugeArray 序列化成一个字符串，塞进内存，再交给 FrankenPHP 发送。这个过程和 Nginx + PHP-FPM 完全一致，FrankenPHP 只是换了个更轻量的运行时，没动底层序列化逻辑。
- FrankenPHP 不自动启用流式输出，也不会重写
JsonResponse行为 - 所有数据仍在单次请求生命周期内完成构建，内存峰值取决于数据体积与 PHP 对象开销
- 若用 Doctrine
findAll()加载 10 万条实体，每条占 2KB，仅对象实例就吃掉 200MB+，远超默认 128M 限制
必须改用 StreamedResponse + 手动 JSON 流格式
真正能绕过内存限制的，是放弃“先组装、再发送”，改为“边查边写”。FrankenPHP 对 php://output 的流支持良好，但前提是 Symfony 响应必须是 StreamedResponse，且回调中严格控制输出节奏。
- 不能依赖
JsonResponse，它天生非流式；必须显式构造StreamedResponse - 回调函数开头必须调用
ob_end_clean()，否则 FrankenPHP 可能缓存首块输出导致延迟或截断 - JSON 流需手动维护语法合法性：数组开头输出
"["，每条记录后加","，最后补"]"；对象流则用"{"/"}"包裹并确保字段间逗号分隔 - 推荐用 Generator 驱动：从数据库游标逐行 fetch，
yield一条就echo json_encode($row)+flush()，内存占用恒定在 ~1–2MB
FrankenPHP 特有的缓冲陷阱：implicit_flush 和 sendfile
FrankenPHP 在 HTTP/2 Server 模式下默认禁用 sendfile，这对流式输出是好事；但它对 implicit_flush 的行为更敏感——如果 php.ini 里 implicit_flush=Off（生产环境常见），仅靠 flush() 不足以推数据，必须配合 ob_flush()。
立即学习“PHP免费学习笔记（深入）”；
- 安全写法是：
echo $chunk; ob_flush(); flush();—— 少任何一个都可能卡住 - 不要设
Content-Length头，流式响应无法预知总长度，FrankenPHP 会自动用Transfer-Encoding: chunked - 若用
fpassthru()输出大文件，确保文件句柄来自fopen('php://output', 'w')而非临时磁盘路径，否则 FrankenPHP 无法流式代理 - 测试时用
curl -N（禁用 buffer）观察实时输出，比浏览器更可靠
最易被忽略的一点：FrankenPHP 的 HTTP/2 Server 模式下，连接复用更激进，若流式响应中途出错（比如数据库连接断开），TCP 连接不会立即关闭，客户端可能长时间等待。务必在 Generator 回调里做 try/catch PDOException，并主动 echo "null" + flush() 后 exit，避免半开连接堆积。
