flush()后内存不降是因为unitofwork仍持有实体引用；需flush()+clear()+gc_collect_cycles()三步联动，并避免findoneby缓存、改用流式读取和显式unset。
为什么 flush() 后内存还不降？
Doctrine 的 flush() 只把变更同步到数据库，并不自动清空 UnitOfWork 中的对象引用——这些对象仍被 EntityManager 持有，持续占内存。尤其在循环中反复 persist() 却不清理，UnitOfWork 会越滚越大，直到脚本结束才释放。
必须配合 clear() + gc_collect_cycles()
仅调用 flush() 不够，关键三步要连做：
-
$em->flush()：提交当前批次的 SQL -
$em->clear()：清空 EntityManager 管理的所有实体，断开对已持久化对象的强引用 -
gc_collect_cycles()：强制触发 PHP 垃圾回收，真正释放内存（尤其在 CLI 脚本中效果明显）
示例节选：
foreach (array_chunk($rows, 100) as $batch) {
foreach ($batch as $row) {
$entity = new Entity($row);
$em->persist($entity);
}
$em->flush();
$em->clear(); // ? 这步不能少
gc_collect_cycles(); // ? 别依赖自动 GC
}
别让 findOneBy 成为内存黑洞
在批量导入中频繁调用 findOneBy() 查重，Doctrine 默认会把查到的实体也注册进 UnitOfWork。如果查了 1 万次，就可能缓存 1 万个实体——哪怕你没改它们。
更轻量的做法：
- 用原生 SQL 查询 ID 或存在性（如
SELECT id FROM table WHERE name = ?），绕过 ORM 实体管理 - 若必须用 Repository，查完立刻
$em->detach($entity)断开跟踪 - 避免在循环内反复查同一张表；可先批量
SELECT所有已存在 name → 构建in_array()缓存数组
生成器读文件 + unset 大变量
Excel 或 CSV 文件本身就会吃掉大量内存。不要用 file_get_contents() 或 fgetcsv() 一次性全读进数组。
推荐做法：
- 用
fopen()+fgets()行级流式读取，配合yield返回单行数据 - 处理完每行后，显式
unset($row)，尤其当$row是含大字段的关联数组时 - 每批处理完（比如 100 行），再
unset($batch)，防止数组隐式累积
容易被忽略的是：PHP 的内存统计（memory_get_usage()）不包含未回收的循环引用。真正压测时，得看 memory_get_peak_usage(true) —— 那才是 OOM 杀手的真实阈值。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
