在 PHP 8.4 里给一个百万级数组随便加个字符串 Key，内存直接暴涨 25 MB

很多 PHP 开发者习惯把数组当成万能容器，但其实 PHP 数组在底层有两种完全不同的存储形态：一种是类似 C 语言数组的「紧凑列表（Packed List）」，另一种是真正的「哈希表（Hash Table）」。只要你的数组保持 0, 1, 2... 这种顺序增长的整数索引，PHP 就会用紧凑模式，每个元素只占 16 字节。但一旦你打破了这个规律，哪怕只加一个字符串 Key，整个数组会瞬间从紧凑模式「升级」为哈希表，内存占用直接翻倍。

我用 PHP 8.4.21 的官方 Docker 镜像（php:8.4-cli）在 64 位 Linux 上实测了一下，把 memory_limit 设为 -1 排除干扰。结论非常震撼：100 万个整数的紧凑数组占 16.8 MB，但只要我执行 $a['x'] = 0; 给它加一个单字符的 Key，内存立刻增加 25,161,728 字节。最坑的是，用 unset 把这个 Key 删掉，内存根本不会回退，因为 PHP 没提供把哈希表转回紧凑列表的机制（除非你用 sort() 或 array_values() 重新生成）。

如果你想验证这个内存黑洞，可以用下面这段简单的代码，核心就是用 memory_get_usage() 算差值：

<?php
$N = 1000000;
$before = memory_get_usage();
$a = [];
for ($i = 0; $i < $N; $i++) {
    $a[$i] = $i;
}
echo "Packed list: " . (memory_get_usage() - $before) . " bytes\n";

$before = memory_get_usage();
$a['x'] = 0;
echo "After adding one string key: " . (memory_get_usage() - $before) . " bytes\n";

我在对比测试中发现了一个更隐蔽的坑：填充顺序。

如果我用 for 循环从 0 到 N-1 填充，它是紧凑的；但如果我用同一个 Key 集合，只是从 N-1 倒着填充到 0，结果完全不同。同样的 100 万个整数，正序填充占 16.78 MB/elem，倒序填充直接飙到 41.94 MB/elem。原因很简单，倒序填充让 PHP 认为这不是一个连续的列表，直接把它当哈希表处理了。

这就是为什么在处理海量数据查询结果时，如果每一行都是关联数组（Associative Array），内存开销会非常恐怖。相比之下，SplFixedArray 的表现要稳得多，100 万个整数只占 16 MB 左右。

总结一下我的实操发现：

• 内存成本： 在 PHP 8.4 中，单个字符串 Key 触发的模式转换会导致内存增加约 25 MB。
• 不可逆性： unset 无法将哈希表还原为紧凑列表。
• 性能建议： 处理大数据集时，尽量维持 0 索引且正序填充，或者直接上 SplFixedArray。

这个发现让我意识到，很多 legacy 代码里的内存泄漏或者莫名其妙的 OOM，可能就是因为在某个环节给大数组随手加了一个描述性的 Key，导致整个数据结构在底层发生了质变。