Symfony命令行处理Excel导入导出的核心是避免内存爆炸：导入用RowIterator流式逐行读+每500行flush/clear+预查关联映射；导出用分页查询+流式写入或CSV替代，禁用ORM缓存与SQL日志。
在 Symfony 中用命令行处理 Excel 导入导出，尤其面对万级、百万级数据时，核心矛盾不是“能不能做”，而是“怎么避免内存爆炸、卡死、超时”。关键不在框架本身，而在读写方式、数据库交互和资源生命周期的精细控制。
导入：别加载整张表，用流式 + 分批
直接 $reader->load($file) 读取大文件，等于把整个 Excel 解析成 PHP 对象树——20 万行就可能吃光 1GB 内存。必须绕过全量加载：
- 用
RowIterator逐行遍历，跳过表头：$iterator = $worksheet->getRowIterator(2)，避免getCell('A1')这类随机访问 - 每 500 行执行一次
$em->flush()，再调$em->clear()清空一级缓存，防止 Doctrine 持有全部实体引用 - 提前查好关联数据（如根据“部门名”找“部门ID”），建索引数组映射：
$deptMap = array_column($depts, 'id', 'name')，别在循环里反复查库 - 关闭 SQL 日志：
$em->getConnection()->getConfiguration()->setSQLLogger(null)，日志对象本身也吃内存
导出：禁用 ORM 缓存，走流式写入
用 Spreadsheet 对象生成百万行，等于在内存里堆百万个 Cell 实例，必然 OOM。正确路径是“分页查 + 流式写”：
- 数据库查询禁用
getResult()全量加载，改用iterate()或游标分页（基于主键/时间戳），例如：WHERE id > :lastId ORDER BY id LIMIT 1000 - 每批查出的数据，不塞进一个大数组，而是立即写入
StreamWriter；推荐用SXSSFWorkbook（PHP 版对应的是PhpSpreadsheet\Writer\Xlsx的流式模式）或直接导出 CSV（无格式要求时最快最省） - 若用 yectep/phpspreadsheet-bundle，注意它不自动处理响应头——命令行场景虽不涉及 HTTP 头，但需确保输出路径可写、临时目录有空间
命令行环境特别注意点
Web 请求有超时和内存限制，命令行看似自由，实则更易踩坑：
- 别依赖默认的
memory_limit，启动命令时显式加大：php -d memory_limit=2G bin/console app:import:excel - 大任务必须加进度提示，比如每处理 1000 行输出一行
echo "✓ 已处理 {$count} 行\n"，否则用户以为卡死 - 避免在命令中做耗时校验（如远程 API 调用、复杂正则匹配），这类逻辑尽量前置或异步化
- 文件路径含中文或空格？先
realpath($inputFile)或urldecode()，防止读取失败静默退出
替代方案：什么时候该换工具
如果业务允许格式简化，或数据量持续突破 50 万行，建议跳出 PhpSpreadsheet：
- 导出优先选 CSV：纯文本、无样式、秒级生成，用
fputcsv()配合yield迭代器，内存恒定在 KB 级 - 导入可考虑
spout库（轻量、原生支持 xlsx/xls/csv、纯流式），比 PhpSpreadsheet 更低内存占用，且无 Composer 依赖冲突风险 - 超大数据（如每日百万订单）应转为异步：命令只负责解析并推入 Redis 队列，另起消费者进程批量写库，解耦上传、解析、入库三阶段
