frankenphp worker模式下ob_start缓冲不会跨请求残留，因其生命周期严格绑定单次请求上下文，请求结束自动清理；所谓“残留”实为缓存干扰、全局状态污染或错误初始化所致。
FrankenPHP Worker 模式下 ob_start 缓冲不会跨请求残留
结论很明确：不会。FrankenPHP 的 Worker 模式基于 PHP-FPM 的 opcache.preload + worker 进程模型，每个请求在独立的协程（不是传统线程）中执行，ob_start() 开启的缓冲区生命周期严格绑定于当前请求的 PHP 执行上下文 —— 请求结束时所有活跃缓冲区自动 ob_end_flush() 或 ob_end_clean()，不存在“残留”到下一个请求的可能。
为什么有人觉得“残留”？常见误判场景
实际观察到的“上个请求内容出现在下个响应里”，几乎都源于以下几类非缓冲区机制问题：
- 缓存层干扰：CDN、反向代理（如 Caddy/Nginx）或浏览器缓存返回了旧响应，而非 FrankenPHP 输出了残留内容
- 全局变量或静态属性污染：在 Worker 全局作用域（如 preload 文件）中定义了
static $buffer或未重置的类状态，被后续请求复用 - 错误地在
onWorkerStart或 preload 阶段调用了ob_start()：该调用发生在进程初始化期，但缓冲区无法跨请求维持；更可能直接导致 fatal error（因无输出上下文） - 使用了
ob_gzhandler等内置 handler 且未正确配置zlib.output_compression：压缩状态可能被底层 zlib 库意外延续，但这属于扩展行为异常，非 ob 机制本身
验证是否真有残留：三步快速排查
不用猜，直接看运行时状态：
- 在请求入口第一行加：
var_dump(ob_get_level());—— 正常应始终为0，若大于0说明有未关闭的缓冲区（但仅限当前请求） - 在请求末尾加：
var_dump(ob_list_handlers());—— 应返回空数组[]，否则说明有活跃 handler 未被ob_end_*()终止 - 用
curl -I查看响应头中的X-Powered-By或自定义头，确认是否与预期请求逻辑一致；配合time参数或随机 query string 强制绕过所有缓存
Worker 模式下 ob_start 的正确用法边界
FrankenPHP Worker 对输出缓冲的要求比传统 FPM 更严格，关键点在于“不可依赖隐式刷新”：
-
ob_start()必须在每次请求的业务逻辑内显式调用，不能放在 preload 或 onWorkerStart 中 - 必须配对使用
ob_end_flush()或ob_end_clean()，避免依赖脚本结束时的自动 flush（Worker 协程复用可能导致行为不稳定） - 嵌套缓冲（多次
ob_start()）可行，但每层都需对应ob_end_*()，且注意回调函数中禁止调用任何ob_*函数（会 fatal） - 若用于页面缓存，务必在写入文件前用
ob_get_contents()获取内容，再立即ob_end_clean()，否则缓冲区可能被后续中间件意外读取
真正容易被忽略的是：FrankenPHP 的 Worker 进程会复用 PHP 执行环境，但 ob 缓冲区是 per-request 的；所有“残留感”几乎都来自外部缓存、静态状态或错误的初始化时机 —— 而不是 ob_start 本身跨请求存活。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
