php数组大数据处理易致内存暴涨、性能骤降，因其底层为哈希表+双向链表，每个zval含冗余元数据，内存占用达原始数据3–5倍；应避免全量加载，改用流式解析、splfixedarray、generator、分片及外部存储等方案。
PHP 数组在大数据量处理中容易出现内存暴涨、性能骤降甚至脚本崩溃，核心原因在于其底层实现是“哈希表+双向链表”的混合结构，每个元素都携带大量元数据，且不支持真正的流式处理或内存映射。
内存占用远超预期
PHP 数组不是紧凑的连续内存块。每个元素（zval）包含类型、引用计数、垃圾回收标记等字段，加上哈希桶、指针开销，实际内存消耗常达原始数据的 3–5 倍。例如：100 万条简单整数，理论上约 8MB，PHP 数组却可能占用 40MB+ 内存。
- 用 memory_get_usage(true) 查看真实分配内存，而非 memory_get_usage()
- 避免一次性 file('large.log') 或 json_decode($big_json, true)，它们直接生成完整数组
- 对日志、CSV、JSON 流，改用逐行/逐段解析（如 fgets、JsonStreamingParser）
遍历与查找效率随数据量非线性下降
虽然键查找平均 O(1)，但哈希冲突增多、CPU 缓存失效、内存页频繁换入换出，会使百万级数组的 foreach 或 in_array 明显变慢；排序（usort）、去重（array_unique）更会触发全量拷贝和多次 realloc。
- 用 isset($arr[$key]) 替代 in_array($key, array_keys($arr))
- 需排序时，优先考虑数据库 ORDER BY 或外部工具（sort 命令），而非 PHP usort
- 去重场景可改用 SplFixedArray + 手动索引管理，或分批处理 + 外部存储（Redis Set、临时表）
缺乏原生分块与迭代器支持
PHP 数组本身不可暂停、不可序列化中间状态，无法像 Python 的 generator 那样边生成边消费。大数组一旦生成，就全程驻留内存，无法释放已处理部分。
立即学习“PHP免费学习笔记（深入）”；
- 用 SplFixedArray 替代普通数组存储纯数值/固定结构数据，减少 zval 开销
- 对需多次遍历的大集合，封装为 Iterator 或 Generator，按需 yield 单条记录
- 必要时将中间结果写入临时文件或 Redis，用 key 分片（如 user_1000001–1001000）控制单次加载量
GC 压力与超时风险
大数组创建和销毁会显著拖慢 PHP 的循环引用 GC，尤其在 CLI 模式下未主动调用 gc_collect_cycles() 时，内存可能持续累积；同时脚本执行时间极易突破 max_execution_time。
- 处理前设置 set_time_limit(0) 和 ini_set('memory_limit', '-1')（仅限 CLI）
- 每处理 N 条后手动触发 gc_collect_cycles()，并用 unset() 显式释放不再需要的子数组
- 关键任务拆分为多个短生命周期进程（如通过 exec 调用多个 php 子脚本）
不复杂但容易忽略：大数据量从来不是“数组能不能装下”的问题，而是“是否必须用数组一次装下”的问题。合理绕过数组、用对工具，比优化数组本身更有效。
