向数组推入undefined/null导致内存暴涨？技术求助

这问题挺典型的，刚好我之前研究过V8引擎的数组存储机制，来给你唠唠：

核心原因：JS数组的底层类型切换 #

你猜的方向完全正确——JavaScript数组在底层可不是“一锅端”的通用容器，以Chrome/Node.js用的V8引擎为例，它会根据数组里的元素类型，自动切换存储模式：

• 当你存的全是**小整数（SMI，比如1）**时，V8会用PACKED_SMI_ELEMENTS这种紧凑格式存储。这种模式下，元素直接存在连续内存块里，每个小整数只占4字节，内存利用率极高，扩容也很保守。
• 一旦你存入null或undefined，情况就变了：这俩属于非SMI类型的特殊值，会触发数组的元素种类升级。升级后的数组会变成PACKED_GENERIC_ELEMENTS模式——这种模式下，数组存的不再是值本身，而是指向引擎内部对象的指针（64位系统上每个指针占8字节）。

但光指针翻倍还不至于2分钟涨90MB，关键在于扩容策略的变化：SMI数组的扩容是小步递增，而通用类型数组为了减少后续内存分配的开销，会预分配更大的内存块。如果你的数组持续增长，每次扩容的预分配量会比SMI数组大很多，叠加起来就会出现内存骤增的情况。

怎么验证这个猜想？ #

你可以用Chrome DevTools的内存快照工具实锤：

• 先跑只存1的代码，拍一次内存快照，找到你的historicalValues数组，查看它的元素类型（在快照的「Summary」或「Retainers」面板里能看到）。
• 再跑存null/undefined的代码，拍快照对比，看看数组的类型是不是变了，内存增长的大头是不是数组本身的预分配内存。

另外也可以检查下：你确定valueToSave就是单纯的null/undefined吗？有没有可能它是某个大对象的引用（比如不小心绑定了DOM元素、大缓存对象），只是表面上看起来是null？不过你说确定不是，那这个可能性可以排除。

怎么解决？ #

如果业务允许的话，最简单的办法是把null/undefined转换成一个特殊的小整数（比如-1），让数组保持在SMI模式，内存占用就会回到正常水平。

要是必须存null/undefined，可以手动控制数组的长度，避免引擎过度预分配——比如定期把数组拆分成多个小数组，或者用Array.prototype.splice清理不需要的元素（不过得注意不要破坏业务逻辑）。

内容的提问来源于stack exchange，提问作者jomak73