数组分块这件事看起来简单到不值一提——不就是把一个大数组切成几个小数组吗但我在实际项目里踩过的坑告诉我越是看起来简单的东西越容易在细节上翻车。比如分块之后原数组被意外修改了、边界条件没处理好导致最后一块数据丢失、用reduce实现分块时性能拉胯、分块大小传了个负数直接死循环……这些问题我都遇到过。这篇文章就是把我这些年在前端开发中积累的数组分块经验完整梳理一遍从最朴素的slice方案到reduce的函数式写法再到Array.from的花式操作每种方法的适用场景、性能表现和避坑要点都会讲到。不管你是刚接触JavaScript的新手还是已经写了几年业务代码的老手相信都能从中找到一些之前没注意到的细节。1. 数组分块到底在解决什么问题1.1 从实际业务场景说起先别急着看代码我想先聊聊为什么会有“数组分块”这个需求。你可能会想一个数组好好的为什么要把它切成一块一块的直接遍历不就行了吗事情没这么简单。我举几个我自己遇到过的真实场景。第一个场景是批量请求接口。后端有个接口一次最多只能接收100个ID但你手上有一个包含5000个用户ID的数组需要查询。这时候你就必须把这5000个ID按100一组切成50块然后分批发送请求。如果不做分块要么接口直接报错要么后端默默截断数据导致结果不完整。第二个场景是大数据量渲染。假设你从接口拿到了一万条数据要渲染成列表如果一次性全部塞进DOM浏览器直接卡死给你看。合理的做法是按每屏能展示的数量分块配合虚拟滚动或者分页加载一块一块地渲染。第三个场景是并发控制。你有100个异步任务要执行但浏览器对同一域名的并发请求数有限制通常是6个左右你需要把任务数组分成若干块每块控制在合理数量内依次执行。还有一个场景可能很多人没注意——文件分片上传。一个大文件被读成ArrayBuffer之后你需要按固定大小切成多个分片分别上传最后在服务端合并。这本质上也是数组分块只不过操作的是二进制数据。所以你看数组分块不是什么学院派的理论练习它是实实在在的业务需求。理解了这个前提我们再来看具体怎么实现。1.2 核心需求拆解分块函数应该满足什么条件在动手写代码之前我习惯先把需求理清楚。一个合格的数组分块函数我认为至少要满足以下几个条件。第一不修改原数组。这是最基本的要求。分块操作应该是纯函数输入一个数组返回一个新的二维数组原数组保持不变。我见过太多人用splice来实现分块结果原数组被掏空了后续代码全部报错。第二处理边界情况。数组长度不能被块大小整除时最后一块应该包含剩余的元素而不是被丢弃。数组为空时应该返回空数组。块大小大于数组长度时应该返回只包含一个块的数组。第三参数校验。块大小必须是大于0的整数。如果传入0或者负数应该抛出错误或者返回空数组而不是陷入死循环。第四性能可接受。对于大规模数组分块操作本身不应该成为性能瓶颈。不同实现方式的性能差异可能达到数倍甚至数十倍。第五语义清晰。代码应该让人一眼就能看懂在做什么不需要额外的注释来解释。这一点在团队协作中特别重要。把这五个条件记住后面我们评估每种实现方案的时候都会对照检查。1.3 常见实现方案概览JavaScript中实现数组分块主流方案大概有这么几种slice for循环最直观、最经典的写法兼容性最好splice while循环代码简洁但会修改原数组需要提前拷贝reduce函数式编程风格代码紧凑但可读性见仁见智Array.from利用类数组构造的特性写法巧妙递归教学意义大于实用价值大数组下有栈溢出风险每种方案都有它的适用场景和局限性。接下来我会逐一拆解每种方案的实现细节、性能表现和注意事项你可以根据自己项目的实际情况选择最合适的。2. 四种主流分块方案的深度拆解2.1 slice方案最稳妥的经典写法如果只能推荐一种分块方案我会毫不犹豫地推荐slice方案。它的逻辑最清晰不会修改原数组性能也足够好。先看代码function chunk(arr, size) { if (!Array.isArray(arr) || size 0 || !Number.isInteger(size)) { throw new Error(参数不合法arr必须为数组size必须为正整数); } const result []; for (let i 0; i arr.length; i size) { result.push(arr.slice(i, i size)); } return result; }就这么几行代码但它把该考虑的都考虑到了。为什么用slice而不是splice这是很多人容易搞混的地方。slice(i, i size)返回的是从索引i到isize不含的一个新数组原数组完全不受影响。而splice(i, size)会从原数组中删除这些元素并返回原数组会被修改。如果你在分块之后还需要用到原数组用splice就是灾难。循环条件为什么是i size因为每次我们取走size个元素下一次的起始位置自然就是i size。当i超过数组长度时循环自动结束不需要额外判断。边界情况怎么处理的假设arr [1,2,3,4,5]size 2。循环过程是i0slice(0,2) → [1,2]i2slice(2,4) → [3,4]i4slice(4,6) → [5]slice会自动处理超出长度的索引i6循环条件不满足结束最后一块只有1个元素slice自动帮我们处理了越界问题不需要手动判断。参数校验为什么这么写Number.isInteger(size)确保size是整数排除了1.5这种奇怪的值。size 0排除了0和负数。!Array.isArray(arr)确保传入的是数组。这三个条件缺一不可。注意有些实现会用size || 1来给size设默认值这在size为0的时候会变成1看起来好像处理了问题但实际上掩盖了调用方的错误。我更倾向于直接抛错让问题暴露出来。性能表现如何slice方案的时间复杂度是O(n)因为每个元素恰好被访问一次。空间复杂度也是O(n)因为返回的新数组包含了所有元素。在我的实测中处理一个100万元素的数组slice方案大约需要15-25毫秒完全够用。2.2 splice方案简洁但有陷阱splice方案的代码看起来更简洁function chunkBySplice(arr, size) { const copy arr.slice(); const result []; while (copy.length 0) { result.push(copy.splice(0, size)); } return result; }注意第一行——我先用slice()拷贝了一份原数组。如果不做这个拷贝直接对原数组操作splice原数组会被清空。这是splice方案最大的陷阱。为什么有人会用splice因为splice(0, size)的语义非常直观从开头拿走size个元素。配合while循环代码读起来就像在说“只要还有元素就从开头拿一块”。splice方案的性能问题。splice每次操作都需要移动数组中剩余的元素。第一次splice(0, size)之后剩下的所有元素都要向前移动size个位置。第二次再移动第三次再移动……总的时间复杂度实际上是O(n²/size)。对于小数组无所谓但如果数组有几十万个元素splice方案会比slice方案慢很多。我做过一组对比测试处理10万个元素的数组块大小为100方案耗时毫秒原数组是否被修改slice3.2否splice已拷贝18.7否splice未拷贝15.3是reduce8.5否Array.from5.1否可以看到splice方案即使拷贝了原数组耗时也是slice方案的近6倍。数据量越大差距越明显。那splice方案还有使用场景吗有。如果你确实需要“从数组中不断取出元素”这个语义比如实现一个任务队列每次取一批任务执行取完就没了那splice反而更合适。但纯粹的分块操作我不推荐用splice。2.3 reduce方案函数式爱好者的选择reduce方案的写法是这样的function chunkByReduce(arr, size) { if (!Array.isArray(arr) || size 0 || !Number.isInteger(size)) { throw new Error(参数不合法); } return arr.reduce((acc, _, index) { if (index % size 0) { acc.push(arr.slice(index, index size)); } return acc; }, []); }reduce方案的思路是什么它遍历数组的每个元素但只在索引是size的整数倍时才执行分块操作。比如size2时索引0、2、4、6……这些位置触发slice其他位置什么都不做。这种写法的优点是代码紧凑一行reduce搞定符合函数式编程的风格。如果你团队里的人都熟悉reduce这种写法看起来很优雅。但缺点也很明显。首先它遍历了数组中的每一个元素但实际上只有n/size个元素需要触发操作其余元素的遍历是浪费的。其次reduce的回调函数中使用了外部变量arr这破坏了reduce的纯函数特性。再次可读性其实不如slice方案——一个不熟悉reduce的同事看到这段代码可能需要想几秒钟才能理解。性能方面reduce方案比slice方案慢一些因为reduce本身的函数调用开销比普通for循环大。在我的测试中10万元素、块大小100的情况下reduce方案耗时约8.5毫秒是slice方案的2.6倍。对于大多数业务场景这个差距可以忽略但如果你在处理大规模数据还是建议用slice方案。实操心得reduce方案有一个隐藏的坑——如果数组中有稀疏元素比如[1, , 3]reduce会跳过空位但slice不会。这可能导致两种方案产生不同的结果。在大多数业务场景中不会遇到稀疏数组但如果你在处理用户输入或者外部数据最好先确认一下。2.4 Array.from方案巧妙但需要理解原理Array.from方案的写法可能是最“聪明”的function chunkByFrom(arr, size) { if (!Array.isArray(arr) || size 0 || !Number.isInteger(size)) { throw new Error(参数不合法); } return Array.from( { length: Math.ceil(arr.length / size) }, (_, index) arr.slice(index * size, (index 1) * size) ); }这段代码的原理是什么Array.from的第一个参数是一个类数组对象这里我们构造了一个长度为Math.ceil(arr.length / size)的对象也就是最终分块的数量。第二个参数是一个映射函数接收索引index返回对应的分块。为什么说它巧妙因为它直接计算出了最终结果有多少块然后一次性构造出来没有循环中的条件判断也没有reduce中的多余遍历。每个块恰好被访问一次没有浪费。Math.ceil的作用是什么向上取整。比如数组长度是5块大小是25/22.5向上取整得到3说明需要3个块。如果数组长度是4块大小是24/22恰好2个块。性能表现Array.from方案在我的测试中排名第二仅次于slice方案。10万元素、块大小100的情况下耗时约5.1毫秒。它比slice方案稍慢的原因在于Array.from本身的构造开销但差距不大。可读性方面Array.from方案需要读者理解“类数组对象”和“映射函数”这两个概念。对于熟悉ES6的开发者来说不难但对于初学者可能有一定的理解成本。我个人的建议是如果团队整体技术水平较高可以用这种写法如果团队中有新手还是用slice方案更稳妥。3. 手把手实现一个生产级的分块函数3.1 完整代码与逐行解析前面分析了四种方案现在我把它们整合成一个生产级的分块函数。这个函数会包含参数校验、默认值处理、以及完整的错误信息。/** * 将数组按指定大小切分成多个子数组 * param {Array} arr - 待分块的原数组 * param {number} size - 每个子数组的大小必须为正整数 * returns {ArrayArray} - 分块后的二维数组 * throws {TypeError} - 当arr不是数组或size不是正整数时抛出 */ function chunkArray(arr, size) { // 参数校验 if (!Array.isArray(arr)) { throw new TypeError(chunkArray: 第一个参数必须是数组当前类型为 ${typeof arr}); } if (typeof size ! number || !Number.isInteger(size) || size 0) { throw new TypeError(chunkArray: 第二个参数必须是正整数当前值为 ${size}); } // 空数组直接返回 if (arr.length 0) { return []; } // 核心分块逻辑 const result []; const totalChunks Math.ceil(arr.length / size); for (let i 0; i totalChunks; i) { const start i * size; result.push(arr.slice(start, start size)); } return result; }逐行解析一下关键点。参数校验部分我用了typeof size ! number来排除字符串类型的size。你可能会想谁会传字符串进来我告诉你在JavaScript中chunkArray([1,2,3], 2)是完全合法的调用如果不做类型检查2会被隐式转换成2看起来好像没问题但如果传的是abc呢Number.isInteger(abc)返回false会被拦截。但显式地检查typeof更清晰错误信息也更明确。空数组的处理虽然不写这个判断后面的循环也不会执行结果也是[]但显式地返回空数组可以让代码意图更清晰也避免了一些边界情况下的意外。totalChunks的计算用Math.ceil(arr.length / size)直接算出需要多少块然后for循环从0遍历到totalChunks-1。这种写法和前面slice方案的while循环等价但我觉得for循环配合totalChunks更直观一些。3.2 参数校验的边界情况处理参数校验这块值得单独拿出来讲因为这是区分“能跑的代码”和“生产级代码”的关键。size为0的情况。如果不做校验arr.slice(0, 0)返回空数组然后i 0导致i永远不变死循环。浏览器直接卡死。这是最危险的情况。size为负数的情况。arr.slice(0, -1)会返回除了最后一个元素之外的所有元素这显然不是我们想要的分块行为。而且i -1会让i越来越小循环永远不会结束。size为小数的情况。arr.slice(0, 2.5)实际上等同于arr.slice(0, 2)因为slice会自动取整。但i 2.5会导致索引出现小数后续的slice行为变得不可预测。所以必须用Number.isInteger拦截。arr为null或undefined的情况。如果不检查arr.length会直接报错。用Array.isArray可以同时排除null、undefined、字符串、对象等所有非数组类型。arr为类数组的情况。比如arguments对象或者DOM NodeList它们有length属性也有索引但不是真正的数组。Array.isArray会返回false。如果你需要支持类数组可以先用Array.from转换一下再传入。注意有些团队的分块函数会允许size为Infinity表示不限制块大小返回整个数组作为一个块。这种需求比较少见如果你的项目有这种场景可以在参数校验中单独处理。3.3 性能优化什么时候该考虑手动优化对于大多数业务场景前面写的chunkArray函数已经足够好了。但如果你在处理特别大的数组比如百万级别或者分块操作在热路径中被频繁调用可以考虑一些优化手段。预分配结果数组的长度。JavaScript的数组是动态的push操作在数组容量不足时会触发扩容。如果我们提前知道需要多少块可以用new Array(totalChunks)预分配然后通过索引赋值而不是push。function chunkArrayOptimized(arr, size) { if (!Array.isArray(arr) || !Number.isInteger(size) || size 0) { throw new TypeError(参数不合法); } const totalChunks Math.ceil(arr.length / size); const result new Array(totalChunks); for (let i 0; i totalChunks; i) { result[i] arr.slice(i * size, (i 1) * size); } return result; }预分配的优势在数组很大时才能体现出来。我实测下来对于10万元素的数组预分配版本比push版本快大约10%-15%。对于几千个元素的数组差距在误差范围内。避免在循环中重复计算arr.length。虽然现代JavaScript引擎会优化这一点但把arr.length缓存到变量中仍然是一个好习惯特别是在循环条件中。使用TypedArray。如果你处理的是纯数字数组并且对性能有极致要求可以考虑使用TypedArray如Int32Array。TypedArray的slice操作返回的是新的TypedArray内存布局更紧凑在大数据量下性能优势明显。但TypedArray不支持动态长度需要提前知道总长度而且不能存储对象类型。关于性能优化的一个原则先测量再优化。不要凭直觉觉得哪里慢就改哪里。用console.time和console.timeEnd或者performance.now()实际测一下找到真正的瓶颈再动手。4. 实战场景与常见问题排查4.1 批量请求中的分块应用前面提到过批量请求接口的场景这里展开讲一下具体怎么实现。假设后端接口/api/users?ids1,2,3一次最多接收100个ID我们有一个包含5000个ID的数组。async function batchFetchUsers(allIds, batchSize 100) { const idChunks chunkArray(allIds, batchSize); const results []; for (const chunk of idChunks) { const response await fetch(/api/users?ids${chunk.join(,)}); if (!response.ok) { throw new Error(请求失败: ${response.status}); } const data await response.json(); results.push(...data); } return results; }这里有几个细节值得注意。batchSize默认值设为100和后端接口的限制保持一致。如果后端限制改了只需要改这一个地方。用for...of遍历分块而不是forEach因为forEach不支持await。for...of会等待每个请求完成后再发下一个实现了串行执行。如果你希望并发执行以提高效率可以用Promise.all但要注意控制并发数量避免同时发出太多请求。results.push(...data)使用了扩展运算符如果data数组很大可能会触发“Maximum call stack size exceeded”错误。更安全的写法是results.push.apply(results, data)或者直接用results results.concat(data)。并发控制的改进版本async function batchFetchWithConcurrency(allIds, batchSize 100, concurrency 3) { const idChunks chunkArray(allIds, batchSize); const results []; for (let i 0; i idChunks.length; i concurrency) { const concurrentChunks idChunks.slice(i, i concurrency); const responses await Promise.all( concurrentChunks.map(chunk fetch(/api/users?ids${chunk.join(,)}).then(r r.json()) ) ); responses.forEach(data results.push(...data)); } return results; }这个版本每次并发发送3个请求既提高了效率又不会给服务器太大压力。concurrency的值可以根据实际情况调整一般建议在3-6之间。4.2 分块与虚拟滚动的配合前端渲染大量数据时虚拟滚动是常用的优化手段。虚拟滚动的核心思路是只渲染可视区域内的元素滚动时动态替换内容。分块在这里的作用是配合数据的分页加载。假设每屏能显示20条数据我们每次加载5屏的数据也就是100条。当用户滚动到距离底部还有2屏时触发下一批数据的加载。const SCREEN_SIZE 20; const PREFETCH_SCREENS 5; const BATCH_SIZE SCREEN_SIZE * PREFETCH_SCREENS; // 100 let allData []; let currentOffset 0; async function loadMore() { const response await fetch(/api/data?offset${currentOffset}limit${BATCH_SIZE}); const newData await response.json(); allData allData.concat(newData); currentOffset newData.length; renderVisibleItems(); } function onScroll() { const scrollTop container.scrollTop; const scrollHeight container.scrollHeight; const clientHeight container.clientHeight; const remaining scrollHeight - scrollTop - clientHeight; const threshold SCREEN_SIZE * 2 * ITEM_HEIGHT; if (remaining threshold) { loadMore(); } }分块在这里的角色是什么其实在这个场景中分块更多是概念上的——我们把数据按BATCH_SIZE分成逻辑上的块每次加载一块。但实际实现中我们并不需要真的把allData切分成二维数组只需要记录currentOffset和BATCH_SIZE即可。那什么时候需要真正的分块当你需要在客户端对已加载的数据进行分组展示时。比如聊天记录按日期分组、商品按类别分组、日志按级别分组。这时候chunkArray就派上用场了。4.3 常见问题速查表在实际使用数组分块的过程中我整理了一些常见问题和解决方法问题现象可能原因解决方法原数组被清空使用了splice且未拷贝原数组改用slice或先arr.slice()拷贝最后一块数据丢失循环条件写成了i arr.length - size改为i arr.lengthslice自动处理越界浏览器卡死size为0或负数导致死循环添加参数校验size必须为正整数分块结果为空数组传入的arr不是数组用Array.isArray检查必要时用Array.from转换分块大小不一致size为小数用Number.isInteger校验内存占用过高大数组分块后未释放原数组引用分块后手动将原数组置为nullreduce方案结果异常数组中包含稀疏元素先用Array.from(arr)填充空位性能瓶颈使用splice处理大数组改用slice方案关于内存释放的一个补充。如果你有一个很大的数组分块之后原数组不再需要了建议手动释放引用let bigArray new Array(1000000).fill(0); const chunks chunkArray(bigArray, 1000); bigArray null; // 释放原数组引用让垃圾回收器可以回收内存虽然现代JavaScript引擎的垃圾回收机制已经很智能了但在处理特别大的数据时手动释放引用仍然是一个好习惯。4.4 几个容易踩坑的细节坑一slice的第二个参数是结束索引不是长度。很多人会写成arr.slice(i, size)以为是从i开始取size个元素。实际上arr.slice(i, size)是从i取到size不含当i size时返回空数组。正确的写法是arr.slice(i, i size)。坑二分块后的子数组仍然是原数组元素的引用。如果原数组中存储的是对象分块后的子数组中的对象和原数组中的是同一个引用。修改其中一个会影响另一个。如果需要完全独立的副本需要用深拷贝。const original [{ id: 1 }, { id: 2 }, { id: 3 }]; const chunks chunkArray(original, 2); chunks[0][0].id 999; console.log(original[0].id); // 999原数组也被修改了坑三Array.from的映射函数中不要使用this。Array.from的第二个参数是一个箭头函数时this绑定是词法作用域的。如果你需要访问外部的this建议用变量保存或者使用普通函数。坑四分块大小不是越大越好也不是越小越好。块太小会导致分块数量过多增加管理开销块太大会失去分块的意义。一般来说块大小在10到1000之间比较合理具体取决于你的业务场景。批量请求场景下块大小通常由接口限制决定渲染场景下块大小通常由每屏显示数量决定。坑五注意分块后的索引映射。如果你需要根据分块后的位置反查原数组中的索引记住公式原索引 块索引 × 块大小 块内索引。这个公式在实现分页、定位等功能时很有用。function getOriginalIndex(chunkIndex, innerIndex, chunkSize) { return chunkIndex * chunkSize innerIndex; }5. 不同方案的选择建议与性能对比5.1 各方案综合对比把前面分析的四种方案放在一起做个全面对比对比维度slice方案splice方案reduce方案Array.from方案是否修改原数组否是需拷贝否否时间复杂度O(n)O(n²/size)O(n)O(n)10万元素耗时3.2ms18.7ms8.5ms5.1ms代码可读性高中中中兼容性ES3ES3ES5ES6边界处理自动需手动需手动需手动推荐场景通用队列消费函数式风格追求简洁从表格可以看出来slice方案在各方面表现最均衡。它的性能最好可读性最高兼容性最强边界处理最自然。如果你不确定选哪个选slice就对了。splice方案只在一种场景下推荐使用你需要“消费”一个数组每次取走一块取完就没了。比如任务队列的处理。这种场景下splice的语义最贴切。reduce方案适合函数式编程风格的项目。如果你的代码库中大量使用reduce、map、filter等函数式方法用reduce实现分块可以保持风格一致。但要注意性能和稀疏数组的问题。Array.from方案适合追求代码简洁的场景。一行代码搞定分块看起来很有逼格。但需要读者理解类数组和映射函数的概念对团队技术水平有一定要求。5.2 什么时候不需要分块说了这么多分块的实现但我想提醒一句不是所有场景都需要分块。如果你只是需要遍历数组不需要把结果保存成二维数组那直接遍历就好了不需要先分块再遍历。分块操作本身也有开销虽然不大但没必要浪费。如果你需要的是“从数组中取出一部分”那用slice或者filter更直接不需要分块。如果你需要的是“把数组分成两组”那用partition操作更合适不需要通用的分块函数。分块真正有价值的场景是你需要把一个大数组切分成多个固定大小的小数组并且这些小数组会被分别处理比如分别发送请求、分别渲染、分别存储。只有在这种场景下分块才是必要的。5.3 扩展思考分块与其他数组操作的组合分块操作很少单独使用它通常和其他数组操作组合在一起。这里分享几个我常用的组合模式。分块 map对每个分块执行相同的操作。const chunks chunkArray(data, 100); const processed chunks.map(chunk chunk.map(item transform(item)));分块 reduce对分块结果进行聚合。const chunks chunkArray(data, 100); const total chunks.reduce((sum, chunk) { return sum chunk.reduce((s, item) s item.value, 0); }, 0);分块 filter筛选出符合条件的分块。const chunks chunkArray(data, 100); const validChunks chunks.filter(chunk chunk.every(item item.isValid));分块 flat分块后再展平可以实现一些有趣的效果。// 将数组按每3个元素一组然后每组内反转 const result chunkArray([1,2,3,4,5,6,7,8,9], 3) .map(chunk chunk.reverse()) .flat(); // 结果[3,2,1,6,5,4,9,8,7]这种组合模式在处理矩阵转置、数据重排等场景时特别有用。5.4 一个实际项目中的完整案例最后分享一个我在实际项目中遇到的完整案例。需求是这样的从后端获取一个包含所有订单的数组需要按每10个订单一组展示在页面上每组之间有一个分隔线并且每组可以独立折叠展开。class OrderList { constructor(container, orders, groupSize 10) { this.container container; this.orders orders; this.groupSize groupSize; this.groups chunkArray(orders, groupSize); this.collapsedGroups new Set(); } render() { this.container.innerHTML ; this.groups.forEach((group, groupIndex) { const groupEl document.createElement(div); groupEl.className order-group; const header document.createElement(div); header.className group-header; header.textContent 第 ${groupIndex 1} 组${group.length} 个订单; header.addEventListener(click, () this.toggleGroup(groupIndex)); groupEl.appendChild(header); const body document.createElement(div); body.className group-body; if (this.collapsedGroups.has(groupIndex)) { body.style.display none; } group.forEach(order { const orderEl document.createElement(div); orderEl.className order-item; orderEl.textContent ${order.id} - ${order.title}; body.appendChild(orderEl); }); groupEl.appendChild(body); this.container.appendChild(groupEl); if (groupIndex this.groups.length - 1) { const divider document.createElement(hr); this.container.appendChild(divider); } }); } toggleGroup(index) { if (this.collapsedGroups.has(index)) { this.collapsedGroups.delete(index); } else { this.collapsedGroups.add(index); } this.render(); } }这个案例中chunkArray是整个功能的基础。没有分块就无法实现按组展示和独立折叠。分块大小groupSize设为10是产品经理根据页面布局和用户体验确定的。如果后续需要调整每组数量只需要改这一个参数。这个案例中我踩过的一个坑最初我用splice实现分块结果每次调用render方法时原数组都被清空了第二次渲染就什么都没有了。后来改成slice方案问题解决。这个教训告诉我分块函数一定要用纯函数实现不能有副作用。另一个坑订单数量很大时比如上万条一次性渲染所有分组会导致页面卡顿。后来我改成了懒渲染——只渲染可视区域内的分组滚动时动态加载。分块在这里的作用变成了“按需加载的单位”而不是“一次性全部渲染”。还有一个细节分组标题中显示了每组的订单数量。由于最后一组可能不满groupSize所以不能直接用groupSize而要用group.length。这个细节虽然小但体现了对边界情况的处理。6. 写在最后数组分块这个操作我从入行到现在用了无数次每次都觉得它简单但每次都能从中学到新东西。最开始我只会用for循环加slice后来学会了reduce和Array.from再后来开始关注性能、边界情况和内存管理。这个过程让我明白一个道理编程中真正重要的不是你会多少种写法而是你理解每种写法背后的取舍。slice方案为什么最推荐因为它在这几个维度上取得了最好的平衡性能足够好、可读性足够高、兼容性足够强、边界处理足够自然。它不是最聪明的写法但它是让你最省心的写法。reduce和Array.from方案不是不好它们在某些场景下确实更优雅。但优雅是有代价的——reduce有性能损耗和稀疏数组的坑Array.from有理解成本。如果你的团队能接受这些代价用它们没问题如果不能老老实实用slice。最后分享一个我个人的习惯每次写分块函数的时候我都会在函数内部加一行console.assert来验证结果是否正确。function chunkArray(arr, size) { // ... 分块逻辑 ... console.assert( result.flat().length arr.length, 分块后元素总数应与原数组一致 ); return result; }这行断言在开发阶段能帮你快速发现分块逻辑的错误在生产环境中console.assert不会抛出错误也不会影响性能。算是一个低成本的安全网。数组分块就是这样一个东西——看起来简单但真正写好、用对需要对JavaScript的数组方法、性能特性和边界情况有扎实的理解。希望这篇文章能帮你少踩几个坑写出更靠谱的代码。
