PhpSpreadsheet在Webman中无法处理百万行数据，因其纯PHP实现导致内存溢出；应改用xlswriter扩展配合分块查询、流式写入、协程读取及异步ZIP分片导出。
为什么 PhpSpreadsheet 在 Webman 里撑不住百万行
它纯 PHP 实现，load() 会把整个 Excel 解析成内存对象树，10 万行就常触发 Fatal error: Allowed memory size exhausted；Webman 是 Swoole 常驻进程，一次 OOM 会卡死整个 worker，比 PHP-FPM 更致命。即使关掉缓存（Settings::setCacheEnabled(false)），写入 5 万行后内存也轻松破 200MB，且无法边查边写——必须等 DB::table()->get() 全部返回才开始生成文件。
xlswriter + 分块查询才是 Webman 导出的可行路径
用 C 扩展 xlswriter 替代 PhpSpreadsheet，内存恒定在几 MB，支持真正的流式写入。关键不是“装上就能跑”，而是要配合 Webman 的运行模型：
- 安装必须走
pecl install xlswriter，并在php.ini加extension=xlswriter.so，仅composer require无效 - 不要用
response()->download()，改用php://output直接输出流，手动设Content-Type和Content-Disposition - 必须调用
set_time_limit(0)，否则 Swoole 默认 10 秒超时会中断导出 - 每写入 5000–10000 行后执行
ob_flush()+flush()，否则 Nginx 或浏览器可能一直无响应 - 数据库查询必须分块：用
offset/limit或游标分页，避免count(*)全表扫描
大文件导入不能靠一次性 toArray()
上传的 Excel 文件若超 10MB，$reader->load($file->getRealPath()) 就可能失败或阻塞协程。真实场景下应放弃全量加载：
- 优先选
boxspout：轻量、流式读取、兼容 Swoole 协程，XlsxReader可逐行迭代，内存占用稳定在 2–5MB - 禁用
PhpSpreadsheet\Reader\Xlsx的load()，改用其getCellIterator()或getRowIterator()，但需注意它仍会预加载部分结构，不如 boxspout 彻底 - 解析完每批数据（如 1000 行）立即用
DB::transaction()批量插入，避免长事务锁表 - 若需校验或清洗，把逻辑放进协程
go(function () { ... })，但注意 MySQL 连接池需支持协程，不能混用传统 PDO
异步任务 + ZIP 分片是唯一能落地的方案
单个百万行 Excel 文件体积常超 100MB，浏览器下载易中断、服务端磁盘 I/O 压力大。真正上线必须拆解：
- 导出不生成单个大文件，而是按 10 万行一个 sheet，每个 sheet 写成独立
.xlsx，存临时目录 - 用
ZipArchive合并所有分片，但合并过程不能阻塞 HTTP 请求——必须扔进Worker进程或 Redis 队列异步执行 - 前端轮询
/api/export/status?task_id=xxx获取进度，后端用 Redis hash 存{total: 1000000, done: 320000} - 最终提供 ZIP 下载链接，而非直接响应二进制流；链接带一次性 token，72 小时后自动清理临时文件
分片和异步不是锦上添花，是 Webman 处理百万级 Excel 的刚性前提——漏掉任意一环，上线后就会在凌晨三点收到报警。
