PHP数组因哈希表结构和元数据开销，实际内存远超直觉；应使用memory_get_usage()实测，优先选用SplFixedArray、避免字符串键、合理管理生命周期并流式解析JSON。
PHP数组实际占用内存远超预期
PHP数组本质是哈希表，每个元素都带额外元数据（键类型、引用计数、类型标记等），array(1, 2, 3) 在64位系统上可能占几百字节，不是12字节。用 memory_get_usage() 测量前后的差值才真实，别信“三个int就12B”的直觉。
常见错误现象：json_decode($big_json, true) 后内存暴涨2–3倍；循环中不断 $arr[] = $item 导致底层反复扩容重哈希。
- 用
array_values()+array_keys()检查是否真需要关联键——如果只是索引容器，考虑改用SplFixedArray - 大数据量场景下，避免用字符串做键（
$data['user_12345']），整数键更省内存且更快 -
unset($arr[$key])不会自动收缩底层存储，大量删除后可用$arr = array_values($arr)重建紧凑索引
用 SplFixedArray 替代普通数组的适用边界
SplFixedArray 是连续内存块，无哈希开销，适合已知长度、纯整数索引、读多写少的场景。但它不支持字符串键、动态扩容、foreach 时内部仍会转成普通数组临时结构。
使用场景：缓存预计算结果、批量处理ID列表、图像像素行数据。
立即学习“PHP免费学习笔记（深入）”；
- 初始化必须指定大小：
$arr = new SplFixedArray(10000)，否则退化为普通对象行为 - 赋值必须用
$arr[123] = $val，不能用$arr[] = $val - 转普通数组要显式调用
$arr->toArray()，直接(array)$arr可能出错 - PHP 8.0+ 中
SplFixedArray的count()和遍历性能明显优于大普通数组
json_decode 时避免默认关联数组模式
json_decode($json, true) 返回全关联数组，即使JSON里全是数字索引，也会生成带字符串键的PHP数组，浪费内存且拖慢访问速度。
错误现象：解析百万条日志JSON后，内存居高不下，isset($arr[123]) 比 array_key_exists('123', $arr) 还慢——因为键被存成了字符串。
- 确认JSON结构是纯列表时，用
json_decode($json, false)得到对象，再用$obj->{0}或强制转(array)$obj（注意这步仍会变关联） - 更稳妥：用
json_decode($json, false, 512, JSON_OBJECT_AS_ARRAY)（PHP 7.4+），但注意该标志仅控制顶层，嵌套仍可能出关联数组 - 终极方案：配合
JsonStreamingParser类库流式解析，边读边处理，不全量加载进内存
unset 和 array_splice 后记得检查是否真释放了内存
PHP的垃圾回收不是即时的，unset($big_array) 只减引用计数，若还有变量指向同一zval（比如函数返回引用、全局变量残留），内存不会立刻归还给OS。
容易踩的坑：在CLI脚本中循环处理文件，每次 $data = json_decode(...) → 处理 → unset($data)，但内存不降——其实是 $data 被闭包捕获，或错误用了静态变量缓存。
- 用
xdebug_debug_zval('var_name')查看引用计数和是否为引用 - 循环体内避免使用
static $cache = []，改用局部变量 + 显式unset() - 必要时手动触发GC：
gc_collect_cycles()，尤其在长周期CLI任务中每千次迭代调用一次 - 注意
array_splice($arr, 0, $n)返回被删片段，若忽略返回值，它仍会暂存在内存里，应写成array_splice($arr, 0, $n);并确保无其他变量接收返回值
数组内存问题从来不是单点优化能解决的——键设计、生命周期管理、扩展选择、甚至JSON源头格式，全都咬合在一起。稍微动错一个环节，前面省下的几十MB又填回去了。
