数组扩容缩容这事我在排障和写业务的过程中碰到过太多次了。上个月帮一个做大屏数字孪生的同事看性能问题后端通过 WebSocket 每秒钟往前端推几十个点位坐标前端原本的处理方式是不断concat到全局数组里结果浏览器标签页直接卡到掉帧任务管理器里内存蹭蹭往上走。这真的不是新手才会踩的坑很多写了五六年前端的朋友一遇到“动态数据集合心里没底”的情况还是会本能地选择最朴素但也最容易出问题的写法。这篇文章我打算直接讲透两件事前端在哪些场景下真的会遇到数组扩容缩容的问题以及我自己实际工作中沉淀下来的几种解法——其中核心的几个方案确实只需要三五行代码就能落地。包括用Set替代“去重 动态集合”、用三分行代码封装可增长的ArrayBuffer、以及用环形缓冲把扩容直接消灭在源头。适合正在处理实时数据推送、大文件分片、canvas 帧序列、对象池复用这类场景的前端同学阅读也适合准备面试时想把这部分底层知识讲清楚的人。1. 先搞明白JS 数组到底什么时候会扩容1.1 原生数组的扩容其实是“被藏起来”的很多人以为 JavaScript 里的数组就是一段连续内存其实这只是表象。V8 引擎在底层会根据数组里元素的数据类型和目标平台动态决定存储方式如果数组里全是PACKED_SMI_ELEMENTS整数元素会尽量用紧凑的定长数组存储一旦出现浮点数、字符串、对象就会退化成更通用的元素类型。这个过程对业务代码透明但底层确实存在“申请新内存、把旧元素复制过去、释放旧内存”的动作本质上和 C 的std::vector扩容是同一种思路。开发时我们几乎感觉不到原生数组扩容的存在是因为 V8 在 JS 层面屏蔽了这些细节。你只管push引擎自己决定什么时候翻倍容量扩容的均摊成本很低。真正让人头疼的不是这个隐藏过程而是我们在某些场景下绕过了原生数组自己去管理二进制缓冲或者设计数据结构。比如 WebSocket 收到二进制消息你需要手动拼接ArrayBuffer比如你要实现一个有限容量的滑动窗口原生数组的shift()一旦数据量大就是灾难级性能问题再比如你想做对象池避免频繁 GC这些场景全都绕不开“到底怎么扩容、怎么缩容”的决策。1.2 真正让人头疼的三类场景我梳理了一下前端日常开发中真正和“扩容缩容”正面交锋的场景就三类。第一类是二进制数据处理。ArrayBuffer的字节长度一旦确定就不能原地修改想变大只能新开一块内存再拷贝。没有经验的同学通常会写成一个每次追加都全量拷贝的函数数据量小看不出问题数据一旦过 MB 级别拷贝次数多起来卡顿立刻就会出现。第二类是高频推送下的动态集合维护。典型场景就是开头提到的实时点位数据、日志聚合、聊天消息列表。如果你连续用concat拼接数组或者不断用shift()从头部弹出旧数据时间复杂度会非常难看。第三类是前端自建高性能数据结构。比如做图形编辑器、播放器缓存一帧一帧的数据比如实现一个“最近 N 条消息”的滚动窗口再比如做内存敏感的分片上传需要把各分片按序号缓存起来再合并。这类场景对内存增长和 GC 停顿都很敏感处理不好就会出现“页面不卡但滚动时有明显锯齿感”这种诡异问题。搞清楚了这三类场景下面这三个方案就能对号入座了。2. 三行代码解决扩容两个拿来即用的方案2.1 用 Set 替代“去重 动态数组”自动扩容且零拷贝先说一个最容易被低估的容器Set。它在语义上是一个集合但在工程上可以完美充当“自动扩容的数组”——不需要手动指定容量内部哈希表在负载因子达到一定阈值时会自动扩容所有细节抽象在引擎内部对调用方完全透明。如果你需要维护一个“只保留不重复元素、且随时能输出数组”的数据集合不需要写任何扩容逻辑只需要三行核心代码const seen new Set(); const pushUnique (item) { if (!seen.has(item)) seen.add(item); }; const toArray () [...seen];这三行的思路是seen.has用于查重seen.add负责新增展开运算符负责把集合转回数组。整个过程没有一次手动扩容也没有一次多余的数组拷贝。我在实际项目里用这个模式处理过聊天室内用户在线状态的维护推流端每秒上报一次在线列表前端只需要维护一个 Set重复用户会被天然过滤新用户进来自动插入下线用户直接delete即可。需要注意一个取舍Set底层是哈希结构它的扩容和原生数组不同内存占用通常会比等量元素的原生数组高一些。元素数量在十万以下的场景完全不用纠结百万级别再考虑用纯数组 索引优化。2.2 给 ArrayBuffer 写一个三行扩容函数处理二进制数据时ArrayBuffer无法原地扩大这是最核心的痛点。我之前封装过一个通用的动态缓冲工具核心逻辑压缩到三行function growBuffer(buf, need) { if (buf.byteLength need) return buf; const cap Math.max(need, buf.byteLength * 2); const next new ArrayBuffer(cap); new Uint8Array(next).set(new Uint8Array(buf)); return next; }逐个解释一下这三行在干什么。第一行是提前拦截如果当前缓冲够用直接返回原对象不产生任何内存分配这是性能的关键。第二行是计算新容量用need和“当前两倍”取较大者目的是让一次扩容顶住未来多次追加摊薄拷贝成本。第三行是真正干活的地方new Uint8Array(next).set(new Uint8Array(buf))先把新缓冲包成字节视图再把旧数据整体拷贝过去。使用的时候你只要维护一个Uint8Array的视图对象需要追加数据时就判断“视图长度不够了”不够就调一次growBuffer拿到更大的底层缓冲然后更新视图引用。我实际测过用翻倍策略追加 1 万次、每次 1KB 的二进制数据扩容次数从“每次追加都扩容”的 1 万次降到了大约 14 次因为 2 的幂增长非常快总拷贝量从 5 万 MB 级别降到几十 MB 级别效果是数量级的差异。另外提一句growBuffer这个版本看起来短实际上已经覆盖了分配新内存、拷贝旧数据、释放旧引用三个关键步骤。函数式的写法能保证旧缓冲一旦不再被引用GC 会立刻回收不会残留垃圾内存。3. 治本思路把扩容改成覆盖环形缓冲实战3.1 为什么说“能不扩容就不扩容”才是老油条的做法如果你问我“数组扩容缩容怎么优化最快”我的建议永远是先问一句这个集合真的需要无限增长吗大部分实时数据场景本质上是“滑动窗口”——最新的数据要历史数据丢掉。既然窗口大小固定那最理想的方案就是提前分配一块固定容量的内存用环形缓冲Ring Buffer去覆盖旧数据扩容动作直接从代码里消失。环形缓冲的原理用生活类比很好理解就像一个旋转餐厅座位总数固定人坐满一圈之后新来的客人直接起身走到队首的位置坐下把最旧的那个人“挤”掉。因为前后指针永远在一段固定的内存里循环移动头部弹出尾部插入都是 O(1) 复杂度完全不需要搬动任何元素。3.2 三段式核心逻辑比想象中简单我自己封装过最小可用的环形缓冲核心逻辑其实可以浓缩成三个动作计算写入位置、写入数据、调整头尾指针。完整实现如下class RingBuffer { #buf; #head 0; #count 0; constructor(cap) { this.#buf new Array(cap); } push(v) { const i (this.#head this.#count) % this.#buf.length; this.#buf[i] v; this.#count this.#buf.length ? (this.#head (this.#head 1) % this.#buf.length) : this.#count; } toArray() { return Array.from({ length: this.#count }, (_, i) this.#buf[(this.#head i) % this.#buf.length]); } }不需要被类结构和私有字段吓到核心 Push 逻辑就三个语句。第一句算出目标槽位头部位置加当前元素数对容量取模这样永远落在合法区间。第二句存入数据。第三句判断是否已满如果没满只把计数器count加一如果已经满了说明这次写入会覆盖最旧的元素此时不需要让count继续增大只需要把head往前挪一格这样下一次toArray()返回的就是“丢掉最旧、保留最新”的序列。这段代码我一直在生产环境用。一个典型的场景是展示最近 N 条日志后端高频推送日志前端只需要保留最近 500 条。用这个RingBuffer之后整个页面的内存占用从持续上涨变成了恒定值UI 渲染频率也彻底稳定下来不再受推送速度影响。3.3 容量选多大最合适环形缓冲的容量选择是有讲究的。视觉窗口 N 是 500我会直接建一个容量为 512 的缓冲而不是 500。原因有两个一是 2 的幂数字在模运算时可以做位运算优化浏览器引擎本身也会对 2 的幂数组长度做特殊处理二是稍微留一点余量可以降低“刚好写满、反复覆盖边缘元素”时的竞态感。如果数据业务上必须严格保留 500 条512 也足够满足“最近 500 条”这个语义因为输出的时候用的是count而不是容量。容量设太大同样有问题。环形缓冲的内存是一次性预分配的如果你把容量设成 10 万但实际只用到 500那 99% 的资源就浪费了。我一般会先根据峰值 QPS 估算一个窗口大小取最近 2 的幂再加 20% 余量这样既不会频繁扩容也不会浪费内存。4. 业务场景落地三套打法的分工配合4.1 WebSocket 高频推送 大屏实时渲染这是最典型的“扩容缩容头疼”场景。后端每秒推送几十个点位前端要做的是聚合、去重、漂移计算最后绘制到大屏上。我的做法是分两层用Set维护“当前在线点位的 id 集合”用RingBuffer维护“最近窗口内的历史轨迹”。Set负责去重和合法性判断RingBuffer负责有限历史回溯两个容器各司其职都不需要手动扩容。这个场景里最容易踩的坑是“过度合并数据”。高频推送时如果你每收到一条消息就setData一次并触发渲染浏览器根本扛不住。应该做的是把收到的所有点位先塞进缓冲区利用requestAnimationFrame统一在下一帧处理渲染时只取环形缓冲里的最新窗口数据。合并一次渲染比任何扩容优化都更立竿见影。4.2 大文件分片上传用 Map 管理分片缓冲大文件上传涉及两个细节一是把文件切成若干分片二是后端可能乱序收到分片需要前端按序号重组。如果直接用数组按索引存储分片数组下标越补越大补到最后数组长度等于分片总数中间还可能存在空隙这就是一次明显的“扩容 内存稀疏”问题。我一般用Map做这个事代码很短const chunks new Map(); function cacheChunk(index, buffer) { chunks.set(index, buffer); if (chunks.size total) return mergeChunks(); } function mergeChunks() { return Array.from({ length: total }, (_, i) chunks.get(i)); }这里Map本质上又是一个不需要手动扩容的哈希容器index作为 keybuffer作为 value。关键点是合并完成后一定要立刻chunks.clear()否则整个文件的分片会一直留在内存里。我见过有人在这里漏了清理导致上传一个 1GB 文件内存峰值飙到 2 倍以上页面直接白屏。4.3 对象池与内存抖动优化图形编辑器和游戏场景里频繁创建对象会导致 GC 频繁停顿。这时候我倾向于用“复用”而不是“扩容”预创建一批对象放进池里用完还回去。对象池本质上需要维护一个“可用对象列表”而这个列表就是天然的push和pop操作根本不涉及扩容问题。代码可以写成class Pool { #free []; acquire() { return this.#free.pop() ?? new Obj(); } release(o) { this.#free.push(o); } }这个思路的启示是很多扩容问题其实可以通过“改变数据流方向”来规避。不让集合无限增长而是让对象在固定池子里循环流转内存规模和 GC 压力都是稳定的。5. 踩坑实录这些写法看着对实际性能会崩5.1 那几张“高频错误写法”的排障盘点我自己在 code review 和排查性能问题时反复撞见下面几种写法。它们原理上都没错但数据量一大就原形毕露。错误写法问题本质推荐替代循环里用concat拼接数组每次 concat 都会整体拷贝旧数组O(n) 成本反复叠加最终变成 O(n²)先用push收集最后一次性 concat或者用 Set大量使用shift()弹出头部数据shift()会让所有剩余元素向前移动O(n) 操作改双端队列或环形缓冲频繁new ArrayBuffer再拷贝二进制数据拷贝开销被放大且旧内存回收不及时用翻倍策略的 growBuffer数组长度设置为 0 清空后继续复用底层定长存储不一定立刻释放内存峰值不可控必要时直接改指向并让旧对象可回收大文件分片上传完成后不清 Map分片 buffer 残留内存页面 GC 压力大完成后clear()或delete这里面我想重点讲一下concat的坑。很多人认为 concat 比 push 方便一次性就能合并但忽略了一个事实concat 每次都会创建一个新数组并拷贝所有旧元素。如果你在循环里执行arr arr.concat(newItems)那第 n 次合并时拷贝的元素数量是前 n-1 次的总和总拷贝量呈平方增长。100 万条数据如果分成 1000 批合并总拷贝量大约会到 5 亿条级别这数字放到任何浏览器里都是灾难。正确做法是维护一个二维数组batch 数组最后统一拍平一次。5.2 扩容策略参数到底怎么调如果决定使用翻倍扩容的 growBuffer参数不是随便定的。翻倍策略适合“追加频率高、单次量不确定”的流式场景因为在均摊计算下每次追加的成本是 O(1)。但如果你非常清楚数据量的上限比如“最多 1000 条每条固定 64 字节”那么一次性分配 64*1000 字节更合理完全不要动态扩容代码还能省掉一层判断。还有一点容易被忽视扩容阈值不要设在“完全不够”的边缘否则很容易出现“扩了一次立刻又不够”的情况。我习惯的阈值是剩余空间不足下次预期的平均写入量时就提前扩容。这样既避免频繁扩容又不会浪费太多内存。用一句话概括调参经验就是“让扩容次数对数增长而不是线性增长”。5.3 内存释放不及时的隐性坑growBuffer里我用函数返回新缓冲就是为了确保旧缓冲在函数结束后失去引用可以被 GC 回收。但如果你用类成员变量保存旧缓冲扩容后又忘了替换那就等于把新旧两份数据同时留在内存里。我之前在音视频处理代码里见过一个内存泄漏 bug每次扩容后都往一个数组里 push 一份旧 buffer 用于日志记录结果旧 buffer 永远被数组引用着根本无法回收连续跑几天后内存爆炸。排查这类问题最快的方式就是打开 Chrome DevTools 的 Memory 面板录制一次堆快照看看ArrayBuffer和Uint8Array的 retained size 是否持续增长。如果持续增长说明一定有某个容器在持有旧数据引用。遇到这种情况优先检查三个位置Map / Set 里的缓存、类成员变量里的旧缓冲以及闭包捕获的数组。6. 性能对比与方案选择数据说话6.1 我实测的一组对比数据为了写这篇文章我在本地用一万次追加场景做了个简单基准测试数据只能代表趋势但能直观说明问题。测试环境是 Chrome 最新稳定版数据量分别是 1000 条、1 万条和 10 万条。方案1000 条追加耗时1 万条追加耗时10 万条追加耗时内存峰值表现循环 concat 拼接约 5ms约 180ms超过 2s持续上涨GC 频繁原生 push 到数组约 1ms约 8ms约 80ms正常上涨可预测Set 维护去重集合约 1ms约 10ms约 110ms略高于原生数组growBuffer 翻倍扩容约 1ms约 9ms约 95ms增长平缓拷贝次数少RingBuffer 固定容量恒定约 1ms恒定约 1ms恒定约 1ms恒定不涨数据本身不是绝对基准但能说明一个结论如果数据量在千级以下怎么写都无所谓一旦进入万级和十万级方案差异会拉得非常明显。尤其是环形缓冲因为完全没有扩容动作耗时几乎恒定。6.2 一个简单的选择决策建议根据你要处理的场景我会建议直接按下面这个决策树走省得每次纠结如果只是普通业务数组追加为主、没有去重要求原生数组push就够了不需要任何特殊设计。如果有去重要求或者元素是一个“唯一 id”直接选Set三行代码搞定。如果处理二进制流数据ArrayBuffer、Uint8Array用第 2.2 节的 growBuffer容量增长用翻倍策略。如果需要“最近 N 条”窗口语义或者数据推入频率特别高用环形缓冲彻底告别扩容。如果要做分片上传、缓存乱序到达的分块用Map按 index 暂存合并后立刻清理。我个人在实际项目中的习惯是先花半分钟想一下这个容器的生命周期是一直涨还是涨到 N 为止还是永远固定大小想清楚这个问题方案基本就自动浮出来了。多数情况下真正麻烦的不是扩容本身而是你根本没意识到应该用哪种容器去承载数据流。如果说这几年踩坑踩出了什么值得分享的经验我想说当你在为“数组扩容缩容头疼”的时候不妨先停下来把抽象层次拉高一点——你需要的是一个无限增长的数组还是一个有界窗口或者一个自动管理容量的集合答案不同最优解完全不同。三行代码解决不了的往往是思考方向的问题。