ThinkPHP导出大文件内存爆掉是因为框架默认缓存响应内容，ob_flush无效；须禁用输出缓冲、用StreamResponse+Db::cursor()流式处理，并调优Nginx/PHP-FPM超时与缓冲配置。
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，前面所有优化都白做。
