ThinkPHP 导出大文件时内存爆掉，ob_flush 为什么没用？
不是 ob_flush 没用，是它被 ThinkPHP 的输出缓冲层和框架响应机制拦住了。默认情况下，ThinkPHP 会把整个响应内容先塞进 Response 对象的缓冲区，等控制器方法执行完才统一输出——这时候 ob_flush 再怎么刷，也刷不出去真实 HTTP 流。必须绕过框架默认响应流程，手动控制输出流。
别在控制器里直接 echo + ob_flush + flush，ThinkPHP 中间件和视图层大概率已开启输出缓冲（ob_start），你刷的是内层缓冲，不是发往浏览器的那层导出逻辑必须脱离 return 响应链，改用 exit 或 die 终止框架后续流程务必在输出前调用 ini_set(‘output_buffering’, ‘off’) 和 ini_set(‘zlib.output_compression’, ‘Off’)，否则 PHP 自身压缩或缓冲会吃掉你的流式输出
用 StreamResponse 替代 Response 实现真流式
ThinkPHP 6.1+ 提供了 think\Response\StreamResponse，它是专为流式场景设计的底层响应类，不缓存 body，直接绑定资源句柄。配合 fopen(‘php://output’, ‘wb’) 就能边查边写、边写边发。
不要用 Response::create($data)->header(…)->send()，这是全量响应模式，$data 一进来就占内存正确做法：查一批数据 → 写入 CSV 行（用 fputcsv）→ 立即 fflush($fp) → 下一批，循环中不拼接大字符串注意设置响应头顺序：Content-Type、Content-Disposition、Cache-Control: no-cache 必须在任何输出之前调用 header()，否则 headers already sent 错误
Db::cursor() 和 chunkById() 别混用，游标才是真不占内存
chunkById() 看似分页，实则每次仍要执行 COUNT(*) + 主键范围查询，数据量极大时 OFFSET 越往后越慢，且 chunk 内部仍会把一批结果 load 进内存；而 Db::cursor() 返回 PDOStatement，配合 fetch() 是真正的逐行迭代，内存占用恒定在几百 KB 级别。
用法示例：$cursor = Db::table(‘orders’)->cursor(); while ($row = $cursor->fetch()) { /* 处理单行 */ }不能在 cursor() 查询里用 with() 关联预加载，会强制转成数组加载，失去流式意义如果必须关联数据，改用子查询或 ID 批量 IN 查询，再用 PHP 合并，避免 ORM 自动 JOIN 把整张关联表拖进内存
浏览器和 Nginx 都可能截断长连接，set_time_limit(0) 不够
导出 100 万行 CSV 可能持续 5–20 分钟，期间 PHP 脚本要一直运行，但 Nginx 默认 proxy_read_timeout 是 60 秒，Apache 有 Timeout，浏览器也可能主动断开空闲连接。光设 set_time_limit(0) 和 ignore_user_abort(true) 不解决根本问题。
立即学习“PHP免费学习笔记（深入）”；
Nginx 配置必须加：proxy_buffering off;、proxy_buffer_size 128k;、proxy_busy_buffers_size 256k;、proxy_read_timeout 1800;PHP-FPM 中 request_terminate_timeout 也要同步调大（如 1800），否则 FPM 进程自己会 kill 掉脚本每输出约 1000 行后，建议写一个空格或换行并调用 echo str_repeat(" ", 4096); + ob_flush() + flush()，防止某些代理或浏览器因长时间无数据而关闭连接
真正难的不是写出流式代码，而是确认每一层——PHP 输出控制、Web 服务器代理策略、浏览器接收行为——都允许并维持着这个长连接。少配一个 proxy_buffering off，前面所有优化都白做。
评论(0)