Symfony Console 命令如何优雅地接收及处理大批量 CSV 数据

SplFileObject流式读取是处理大CSV文件的最优方案，需跳过BOM、单独读表头、每500行flush+clear、前置校验路径与格式、导出优先用fputcsv而非PhpSpreadsheet。

直接用 fgetcsv() 或 file_get_contents() 读完整个 CSV，内存很快就会爆掉——万级数据就可能吃光 512MB 限制。真正“优雅”的关键不是功能多全，而是从第一行开始就控制住内存和数据库压力。

用 SplFileObject 流式读取，别碰全量数组

PHP 内置的 SplFileObject 是处理大 CSV 的事实标准，它不把文件全载入内存，而是按需读行。配合 setCsvControl() 可精准适配分隔符、引号和转义符。

• 必须跳过 BOM 头：构造时加 SKIP_EMPTY | DROP_NEW_LINE 标志，或手动 rewind() 后检测前3字节是否为 xEFxBBxBF
• 表头行要单独读一次：$header = $file->fgetcsv()，之后循环用 $row = $file->fgetcsv()，避免在每轮里重复判断
• 别用 iterator_to_array($file)——这等于又把全部内容拉进内存，彻底绕开流式优势

每 500 行 flush + clear，防止 Doctrine 缓存撑爆

$em->flush() 不只是提交事务，更是触发变更单元（UnitOfWork）的持久化；$em->clear() 则清空一级缓存里所有已托管实体引用。两者配合才能让内存回落。

• 计数器别用 $i++ 然后 % 500 === 0，改用 if (++$batchSize >= 500)，避免整除偏差
• $em->clear() 后，后续查询会重新走 SQL，所以关联数据（如根据部门名查 ID）必须提前建好映射数组：$deptIdMap = array_column($depts, 'id', 'name')，别在循环里 $em->getRepository()->findOneBy(['name' => $row[2]])
• 关掉 SQL 日志：$em->getConnection()->getConfiguration()->setSQLLogger(null)，否则日志对象本身也会累积内存

参数校验和路径安全必须前置，别等读到第10万行才报错

命令行参数传错、CSV 路径不可读、字段数量对不上——这些错误应该在 execute() 开头几行就暴露，而不是埋进循环里让用户等三分钟才发现文件打不开。

• 用 $input->getArgument('file') 拿到路径后，立刻检查：is_readable()、filesize() > 0、pathinfo($file, PATHINFO_EXTENSION) === 'csv'
• 用 $io->askConfirmation() 提醒用户：“即将导入约 ".number_format($estimatedRows)." 行，确认继续？(y/N)”——估算行数可用 count(file($file, FILE_SKIP_EMPTY))（小文件）或 shell_exec("wc -l （Linux 大文件）
• 字段数校验放在首行读取后：count($header) !== count($row) 就直接 $io->error("第 2 行字段数异常（期望 {$headerCount}，实际 " . count($row) . "）") 并退出

导出 CSV 时别用 PhpSpreadsheet，优先选原生 fputcsv

如果你只是导出结构化纯文本数据（无样式、无公式），fputcsv() 是唯一合理选择。PhpSpreadsheet 在命令行场景下毫无优势，反而引入巨大内存开销和依赖复杂度。

• 打开文件句柄用 fopen($path, 'w')，立刻 fputcsv($fp, $header) 写表头
• 数据库查数据必须用 $query->iterate() 或游标分页（WHERE id > :lastId ORDER BY id LIMIT 1000），绝不能 $query->getResult()
• 每写一行就 fputcsv($fp, $row)，写完一批（比如 1000 行）调一次 fflush($fp)，确保缓冲区及时落盘

真正难的从来不是“怎么读 CSV”，而是读的过程中始终知道哪块内存属于谁、哪条 SQL 正在拖慢速度、哪个临时变量正在悄悄积累——这些细节不会报错，但会让命令从 2 秒变成 20 分钟。