iterator_to_array()会一次性将整个迭代器加载到内存，不支持惰性求值，导致大目录或大数据集下极易内存溢出；应优先使用foreach直接遍历以保持内存恒定。
iterator_to_array() 会把整个迭代器一次性加载进内存
它不 lazy，也不流式处理——无论你用 DirectoryIterator 还是自定义的 IteratorAggregate，只要传给 iterator_to_array()，PHP 就会立刻遍历全部元素、构造完整数组。对大目录、大数据集或远程流式数据源来说，这等于直接触发 OOM。
常见错误现象：Fatal error: Allowed memory size of XXX bytes exhausted；或者脚本 RSS 内存暴涨几十 MB，远超预期。
- 即使迭代器本身内存友好（比如只 hold 一个文件句柄），
iterator_to_array()也会把所有SplFileInfo对象全塞进数组，每个对象都带完整路径、权限、时间戳等元数据 - 如果迭代器返回的是数据库游标（如 PDOStatement 实现了
Traversable），它会把全部结果集 fetch 到 PHP 用户态内存，绕过流式处理能力 -
iterator_to_array($it, $use_keys = true)的第二个参数默认为true，意味着还要额外维护键映射表，进一步增加开销
和 foreach 遍历相比，内存占用翻倍甚至更高
foreach 是原生语言级遍历，底层复用 C 的迭代协议，每次只取一个值，变量作用域可控；而 iterator_to_array() 必须先建好数组容器，再逐个 append，中间还涉及哈希表扩容、zval 复制、引用计数更新等开销。
实测对比（10 万文件目录）：
memory_get_usage(): ~2MB（foreach 循环中仅保留单个 $file）<br>memory_get_usage(): ~180MB（iterator_to_array($dirIter)）
- 关键差异在于：foreach 中的 $file 在每次迭代后自动释放（refcount 归零即回收）；而
iterator_to_array()返回的数组里，每个元素都是强引用，生命周期绑定到数组本身 - 若数组后续又被
json_encode()或serialize()，还会触发深度复制，内存峰值可能再翻一倍 - 别指望 GC 能及时救场——
gc_collect_cycles()对这种线性引用链基本无效，它主要对付循环引用
替代方案：按需处理，绕过数组构造
绝大多数使用 iterator_to_array() 的场景，其实真正需要的只是“遍历”或“筛选”，而不是“拥有一份完整副本”。强行转数组，本质是思维惯性，不是技术必须。
- 用
foreach直接消费：最轻量，内存恒定，支持break/continue控制流 - 需要随机访问？改用
ArrayIterator包装已有数组，或提前用yield构建生成器（PHP 5.5+） - 要做批量操作（如 insert 多条记录）？用
array_chunk()分批处理，但 chunk 前仍应避免全量加载 - 真要导出结构化数据？考虑
json_encode()配合yield流式输出（如 Swoole HTTP response stream），跳过中间数组
静态缓存 + iterator_to_array() 是双重陷阱
当有人把 iterator_to_array() 结果存进 self::$cache，问题就从“单次内存爆炸”升级为“常驻泄漏”。尤其在 Swoole worker 或 CLI 长任务中，这个数组永远不会被释放。
- 典型错误：
self::$cache[$path] = iterator_to_array(new DirectoryIterator($path)); - 更隐蔽的问题：缓存键没做归一化（比如路径含
./和/full/path被视为不同键），导致缓存无限膨胀 - WeakMap 不适用——因为
iterator_to_array()返回的是数组，不是对象，无法作为 WeakMap 的键 - 修复思路：要么彻底不用缓存，要么缓存前做严格裁剪（只留 filename 和 size，丢弃 SplFileInfo 对象）
真正危险的不是函数本身，而是它掩盖了“是否真的需要全部数据”的设计判断。一旦写上这一行，后续所有优化都得围着它兜底。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
