直接用递归遍历几十MB嵌套数组易内存耗尽或卡死；array_walk_recursive虽能一键扁平化，但一次性加载全部结构到内存，无法中断、分片或获取路径，且静默跳过不可遍历项；应使用生成器+手动递归实现流式分批处理，yield单个带路径键值对，内存驻留仅当前层级元素，并配合深度限制、主动垃圾回收与下游负载适配batch size。
直接用递归遍历几十 MB 的嵌套数组，大概率会 Fatal error: Allowed memory size exhausted 或卡死在某一层——这不是代码写错了，是 PHP 的调用栈和内存模型天然不适合这种操作。
array_walk_recursive 为什么不能用于超大数组
它确实能一键扁平化，但内部仍是一次性加载全部结构到内存，再深度优先遍历。遇到含千级嵌套、百万级叶子节点的数组时，array_walk_recursive 本身不报错，但后续处理（比如写入 DB、序列化）会突然崩掉。
- 它跳过对象、资源、闭包，但不会警告——你拿到的结果可能莫名其妙缺数据
- PHP 8.1+ 会对不可遍历项发
Warning，但默认错误报告级别常关着，实际运行时静默丢数据 - 无法中断、无法分片、无法知道当前路径，纯“黑盒式”遍历
用生成器 + 手动递归实现流式分批
核心是：不拼大数组，不累积结果，只 yield 单个值或带路径的键值对。内存驻留永远只有当前层级的一两个元素。
- 递归函数必须用
yield，不能 return 数组；子调用用yield from转发 - 每层递归前加
is_array($v)判定，避免对字符串/数字调用导致 Warning - 若需键路径（如
a.b.c），把当前键存入临时数组，递归返回时implode('.', $path) - 不要在生成器里做耗时操作（如 DB 查询、HTTP 请求），只做结构解析
function flattenGenerator($array, $path = []) {
foreach ($array as $k => $v) {
$currentPath = array_merge($path, [$k]);
if (is_array($v)) {
yield from flattenGenerator($v, $currentPath);
} else {
yield implode('.', $currentPath) => $v;
}
}
}
// 使用方式：每次只取一条，内存无压力
foreach (flattenGenerator($hugeData) as $key => $value) {
// 处理单条，比如插入数据库、写文件
processItem($key, $value);
// 每 500 条手动切片，不依赖生成器内部逻辑
if (++$count % 500 === 0) {
gc_collect_cycles(); // 主动回收，防长期运行内存缓慢上涨
}
}
分批边界在哪？怎么设 batch size
没有固定数值，取决于你的处理逻辑耗时和可用内存。关键不是“一次处理多少”，而是“不让 PHP 内存持续增长”。
立即学习“PHP免费学习笔记（深入）”；
- 如果
processItem()是纯计算，batch size 可设 1000–5000；如果是带 DB 写入，建议 100–500，避免事务日志过大 - 别用
array_chunk对原始大数组切片——它先复制一份，内存翻倍；应让生成器按计数器主动 yield 分组 - 真实瓶颈常在下游：比如批量 INSERT 时没控制 SQL 长度，导致单条语句超 MySQL packet limit
- 高并发场景下，每个请求的递归深度建议硬限制，比如加参数
$depth <= 20，超限就 throw Exception
真正难的不是写出能跑的递归，而是判断哪一层该停、哪条路径该跳过、哪个值该缓存——这些逻辑没法靠函数自动推导，得你亲手埋在生成器的每一层判定里。
