每个人的备赛与参赛经验，就是在这些最基本的知识点上拉开了差距。我给自己定的目标是：每个高频方法不假思索就能写对。

2. 遍历、筛选、映射：比赛中出场率最高的三个方法

2.1 map：数据清洗和列表渲染的头号工具

map的作用一句话：对数组每一项执行同样操作，返回一个等长度的新数组。它不修改原数组，这很关键。比赛里经常需要对同一份数据做不同视角的展示，你不可能每展示一次就把原数据改一次。

实际比赛里map用得最多的场景是"把原始数据转成页面需要的结构"。比如题目给的JSON里价格单位是分，而页面上要求显示成"¥129.00"；或者原始数据里只有categoryId，但页面上要展示分类名称。这种转换用map写起来最顺手：

const products = [ { id: 1, name: '无线鼠标', price: 12900, categoryId: 2 }, { id: 2, name: '机械键盘', price: 39900, categoryId: 2 }, { id: 3, name: '显示器', price: 159900, categoryId: 1 } ]; const listItems = products.map(p => ({ ...p, priceText: `¥${(p.price / 100).toFixed(2)}`, categoryName: p.categoryId === 1 ? '外设' : '办公' })); console.log(listItems[0].priceText); // ¥129.00

这段代码在比赛里的意义不只是转换数据，它让你后续渲染直接拿listItems的priceText往模板里塞，不用在渲染时再做一次格式判断。我习惯把map当"数据管道"用：用一次map把原始数据处理成页面最终需要的形状，后面所有操作都基于处理后的数组。这样即使数据里有脏数据，也只会在这个环节暴露出来，不会把问题埋到渲染层。

注意：map的回调里如果你用大括号{}，必须写return，否则返回的全是undefined。比赛里最容易出现这种"看起来执行了但结果不对"的bug，写完先在控制台打印确认一下。

2.2 filter：筛选逻辑一个方法搞定

filter从数组里挑出满足条件的项，组成新数组返回。比赛里的筛选需求几乎可以用它一招通吃：分类筛选、价格区间筛选、关键字搜索、库存状态过滤。

拿一个比赛里实际会出现的情况举例：页面有分类按钮组，点击某个分类时只展示该分类下的商品。

let selectedCategory = 'all'; const allProducts = [...]; // 题目提供的原始数据 function getVisibleProducts() { if (selectedCategory === 'all') return allProducts; return allProducts.filter(p => p.category === selectedCategory); }

这里有个细节值得展开：filter后面的回调返回的是布尔值，但判断条件要写完整，不要写成p.price这种"有值就通过"的模糊判断。要先筛"价格大于100的商品"，必须写成p.price > 100。如果条件写反了，筛选结果整个颠倒，比赛测试用例基本都会跑挂，扣分很重。

filter另一个常见组合是和map联动：先filter剔除不需要的数据，再map进行格式化，这是比赛里最经典的两步管道。配合"搜索框输入关键字实时更新列表"这类需求，几乎就是filter的独角戏：

const keyword = '键盘'; const filtered = products .filter(p => p.name.includes(keyword) && p.stock > 0) .map(p => formatter(p));

2.3 forEach：循环本身不坑，坑在使用姿势

forEach和map长得像，但本质区别在返回值。forEach总是返回undefined，它的用途是"对每一项执行操作"，而不是"生成一个新数组"。很多新手在比赛里想创建一个新数组，却用forEach往外部数组push，虽然也能跑，但代码可读性和函数式程度都差很多，调试起来也更费劲。

真正的坑是很多人以为forEach可以像for循环一样break跳出。实际上forEach不能中途停止，一旦遍历就是从头到尾全部执行。比赛场景里如果需要找到第一个满足条件的项就停止，应该用find；如果要对符合条件的数据做批量操作，应该先filter筛选再forEach，这样逻辑更清晰，也更容易检查中间结果。

另外一个实战经验：如果你在forEach里做异步操作（比如批量保存），回调里的异步执行顺序和预期不一样，这种情况在蓝桥杯Web赛里不常考，但我在实际项目里被坑过，这里提一句防止大家以后踩到。比赛中遇到需要"逐个处理并收集结果"的需求，优先考虑map或者for...of，而不是forEach加push。

3. 查找、判断、规约：低频但一用就惊艳的三个方法

3.1 find与findIndex：对象数组查找的正确姿势

比赛里经常要"根据id找到对应数据"，比如点击购物车里某件商品，需要把这条商品的信息取出来。find就是干这个的：遍历数组，返回第一个满足条件的元素，找不到则返回undefined。

const cart = [ { id: 'sku_1001', name: '无线鼠标', qty: 2, price: 12900 }, { id: 'sku_1002', name: '机械键盘', qty: 1, price: 39900 } ]; function findCartItem(id) { return cart.find(item => item.id === id); } const target = findCartItem('sku_1001'); console.log(target?.name); // '无线鼠标'

findIndex则是返回下标，没找到返回-1。它最常用的场景是配合splice做"删除指定项"。你要删除购物车里id为sku_1002的那项，用findIndex拿到下标，再splice一下，就完成了：

const index = cart.findIndex(item => item.id === 'sku_1002'); if (index !== -1) { cart.splice(index, 1); }

注意：删之前一定要判断index !== -1。findIndex没找到时返回-1，而splice(-1,1)会删除数组最后一个元素。这个bug特别隐蔽，页面上看着少了一行数据，但一时半会说不清是从哪丢的，排查起来极浪费时间。

3.2 some和every：判断题型和批量操作里的救星

some判断数组里是否存在至少一个满足条件的元素，every判断是否所有元素都满足条件，两个方法都返回布尔值。比赛里这类需求通常藏在"表单校验"和"批量操作"的题目中。

一个很常见的需求是：批量操作按钮只有当选中的商品中存在缺货项时，才在页面顶部弹出缺货提醒。你可以用some这样判断：

const selectedItems = [ { name: '无线鼠标', stock: 0 }, { name: '机械键盘', stock: 23 } ]; const hasOutOfStock = selectedItems.some(item => item.stock === 0); // hasOutOfStock = true，弹提醒

再比如全选交互：表格里多行数据，每行前面有复选框，需求是当所有行都被选中时，表头的全选框自动变为选中状态。这个逻辑用every写，一行就能完成：

const rows = getTableRows(); const allChecked = rows.length > 0 && rows.every(r => r.checked);

这里的rows.length > 0一定要加。空数组的every恒为true，如果不加这个判断，列表为空时全选框会错误地处于勾选状态，这在比赛测试用例里是一个很经典的陷阱。some对空数组则恒为false，使用时要明白这个差异，避免写出相反的边界逻辑。

3.3 reduce：从累加到对象转换的万能规约

reduce是数组方法里最被低估的一个。很多人觉得它只有求和这一个用途，其实它能在一次遍历中完成几乎所有"数组变单值""数组变对象""数组分组"的操作。

最常见也是最稳的用法是累加统计。比赛中"计算购物车总金额""计算各分类商品数量"这类需求，用reduce写起来既简洁又不容易出错：

const cart = [ { name: '无线鼠标', price: 129, qty: 2 }, { name: '机械键盘', price: 399, qty: 1 } ]; const total = cart.reduce((sum, item) => sum + item.price * item.qty, 0); // total = 657

reduce的第二个参数初始值非常关键。求和场景初始值必须是数字0，如果忘了传初始值，reduce会拿数组第一项当初始值，然后从第二项开始累加。对非数字数组来说，所得结果可能完全出乎意料。

更进阶的用法是把数组按某个字段分组成对象。比赛里如果给你一组销售记录，要求统计各月份的销售额，用reduce比用循环加临时对象写起来高效得多：

const records = [ { month: '2025-01', amount: 3000 }, { month: '2025-02', amount: 4500 }, { month: '2025-01', amount: 2100 }, { month: '2025-02', amount: 1500 } ]; const monthMap = records.reduce((acc, r) => { acc[r.month] = (acc[r.month] || 0) + r.amount; return acc; }, {}); // monthMap = { '2025-01': 5100, '2025-02': 6000 }

注意reduce的回调里一定要return结果，否则下一次遍历拿到的初始值就是undefined，整个计算全乱。这是reduce最容易犯的错，比赛里写reduce却忘了在回调里返回累加器的情况，我见过太多。

提示：如果你觉得reduce难记，就记住一句话——它的回调参数依次是"上一次的结果、当前项、当前下标、原数组"，第二参数是初始值。把这句话刻在脑子里，比背任何文档都快。

4. 排序、切片、拼接：不背下来就会现场翻车

4.1 sort的默认行为是一个经典的坑

sort方法如果不传参数，会把数组元素转成字符串再按Unicode码点排序。这意味着[1, 10, 2, 21]排序结果是[1, 10, 2, 21]而不是[1, 2, 10, 21]。数字排序必须传比较函数：

const nums = [1, 10, 2, 21]; nums.sort((a, b) => a - b); // 升序 [1, 2, 10, 21] nums.sort((a, b) => b - a); // 降序 [21, 10, 2, 1]

字符串的localeCompare也很常用，特别是排序商品名称时。要注意sort是原地修改原数组的，比赛里如果后面还要用原始顺序的数据，必须先拷贝一份再排序：

const original = [3, 1, 4, 1, 5]; const sorted = [...original].sort((a, b) => a - b); // original 不变，sorted 是排序后的新数组

这里展开运算符拷贝很重要。我模拟赛时有一次没拷贝直接sort，结果原数组被改乱了，后续另一个功能还要用原顺序，数据全错，排查了半天才意识到是sort惹的祸。这属于比赛里最冤的丢分方式。

对象数组按属性排序同样需要比较函数，例如商品按价格降序：products.sort((a, b) => b.price - a.price)。这种写法几乎每套题都会考到，一定要背熟。

4.2 slice与splice：一个不改变原数组，一个改变

slice(start, end)从原数组中截取一段，返回新数组，不改变原数组；splice(start, count, ...items)会修改原数组，用于删除和插入。因为拼写太像，比赛里我至少见过三个选手在这俩方法上翻车。

slice是分页的核心工具。列表页每页显示10条，第2页的数据就是整体slice(10, 20)。这个逻辑在蓝桥杯Web赛的列表题里几乎是必考：

const pageSize = 10; const currentPage = 2; const pagedData = allData.slice((currentPage - 1) * pageSize, currentPage * pageSize);

splice则用于删除元素和向指定位置插入元素。前面说过，删除购物车项就是findIndex配合splice。splice的第二个参数是删除的个数，不是结束下标，这个特别容易记错。

还有一个小细节：splice会返回被删除的元素组成的数组，如果只是删除，这个返回值通常用不到，但千万别把返回值和原数组搞混。有些人写代码时把splice的返回值当成删剩下的数组用，结果页面渲染的内容越来越少，最后变成空，查错体验极差。

4.3 join、split与展开运算符：数组和字符串之间的桥

join把数组拼成字符串，默认用逗号分隔。比赛里常见的需求是把选中的标签拼接成用逗号、顿号或斜杠分隔的字符串，比如把['前端', '后端', '测试']拼成"前端、后端、测试"，前端页面直接展示。

const tags = ['前端', '后端', '测试']; const tagText = tags.join('、'); // '前端、后端、测试'

split是join的逆操作，把字符串按指定分隔符拆成数组。这两个方法经常配合用于处理输入框中的内容，比如用户输入"苹果,香蕉,橙子"，先用split(',')转成数组，再trim去空格，再判断是否重复。

展开运算符...在比赛里也有很高的使用率。除了前面说的拷贝数组之外，还有两个高频场景：

// 求数组最大值/最小值（配合Math） const prices = [129, 399, 89, 599]; const maxPrice = Math.max(...prices); // 599 // 合并数组 const list1 = [1, 2]; const list2 = [3, 4]; const merged = [...list1, ...list2]; // [1, 2, 3, 4]

这些看起来基础，但在比赛中能省掉很多手写代码的时间，而且不容易出错。注意Math.max(...prices)如果数组里有NaN或数组为空，结果会变成NaN或-Infinity，使用前确认数据合法性。

5. 一套真题风格的完整链路：筛选、排序、分页、渲染

5.1 把需求还原成一个真实的比赛题目

为了让上面的方法不散落成一堆孤立语法，我模拟一道蓝桥杯Web赛道风格的题目来跑一个完整流程。题目背景：某电商后台需要维护一个商品列表页，原生的HTML页面改造需求如下：

1. 页面加载后展示全部商品；
2. 点击分类按钮（全部/数码/配件/耗材），列表只展示对应分类商品；
3. 输入搜索关键字时，按商品名称模糊匹配；
4. 点击"价格升序/降序"按钮，列表按价格排序；
5. 每页展示4条，支持上一页/下一页翻页；
6. 统计区域显示当前可见商品的总库存。

原始数据结构大概是这样的：

const products = [ { id: 1, name: '无线鼠标', category: '配件', price: 129, stock: 56 }, { id: 2, name: '机械键盘', category: '配件', price: 399, stock: 23 }, { id: 3, name: '4K显示器', category: '数码', price: 1599, stock: 12 }, { id: 4, name: 'USB扩展坞', category: '配件', price: 89, stock: 78 }, { id: 5, name: '降噪耳机', category: '数码', price: 899, stock: 34 }, { id: 6, name: '打印纸A4', category: '耗材', price: 25, stock: 200 }, { id: 7, name: '充电器', category: '配件', price: 69, stock: 45 }, { id: 8, name: '摄像头', category: '数码', price: 299, stock: 18 } ];

5.2 用数组方法构建一个完整的数据管道

我把上面所有需求收敛成一条明确的数组处理链路：先filter两次（分类和关键字）、再sort排序、最后slice分页，中间遇到map做格式转换。整个处理可以写成一个函数：

let state = { category: '全部', keyword: '', sortType: 'default', // 'default' | 'priceAsc' | 'priceDesc' page: 1, pageSize: 4 }; function getVisibleProducts() { let result = [...products]; // 第一步：分类筛选 if (state.category !== '全部') { result = result.filter(p => p.category === state.category); } // 第二步：关键字模糊匹配 if (state.keyword.trim() !== '') { result = result.filter(p => p.name.includes(state.keyword.trim())); } // 第三步：排序 if (state.sortType === 'priceAsc') { result.sort((a, b) => a.price - b.price); } else if (state.sortType === 'priceDesc') { result.sort((a, b) => b.price - a.price); } // 第四步：统计可见商品总库存 state.totalStock = result.reduce((sum, p) => sum + p.stock, 0); // 第五步：分页 const startIndex = (state.page - 1) * state.pageSize; const pageData = result.slice(startIndex, startIndex + state.pageSize); return pageData; }

这个函数的核心思想就是"每一步筛选都重新生成一个新数组，再交给下一步"，每一步的意图都清晰对应需求文档里的一条。比赛阅卷是按行为点给分的，这种写法的可追踪性是最好的——只要页面出了问题，你把result单独打印出来，就能确认是哪一步出错。

要注意先排序再分页这个顺序。如果先分页再排序，只能把当前页的数据排序，整个列表的顺序还是乱的，这是新手最容易犯的逻辑错误。我在模拟赛里就翻过这个车，当时分页后的数据在每页内部是排好序的，跨页就乱，测试对比数据时才暴露问题。

5.3 渲染函数里map的具体用法

数据处理完之后，接下来就是渲染。题目一般不允许你用框架，直接操作DOM或者用模板拼接字符串。在比赛环境下，用map生成HTML字符串数组再join，是最常见也最高效的渲染方式：

function renderList() { const pageData = getVisibleProducts(); const container = document.querySelector('#productList'); if (pageData.length === 0) { container.innerHTML = '<p class="empty">没有匹配的商品</p>'; return; } container.innerHTML = pageData.map(p => ` <tr> <td>${p.id}</td> <td>${p.name}</td> <td>${p.category}</td> <td>¥${p.price.toFixed(2)}</td> <td>${p.stock}</td> </tr> `).join(''); }

map生成HTML字符串然后join拼成一整段，再一次性赋值给innerHTML，好处是减少了DOM操作次数，页面渲染性能好，代码也紧凑。注意模板字符串里要小心改写成自己的数据字段名，别把p.price写成p.prices这类笔误，这种错误在比赛中特别容易发生，而且不会立刻报错，只会显示空白或undefined，肉眼排查很费时间。

5.4 这个方法组合背后的思维方式

这一段我想多说一点。比赛里你不需要背很多方法的标准定义，你需要的是把"数据处理需求"和"数组方法"之间建立映射关系：筛选动作对应filter、变换动作对应map、统计动作对应reduce、查找动作对应find、排序动作对应sort、切片动作对应slice。一旦建立起这个映射表，拿到任何一道题，你只需要把需求翻译成方法名，剩下的就是流水线作业。

我见过有选手习惯于把所有逻辑都塞进一个for循环里，循环里if套if，最后代码有七八层缩进，出问题完全没办法调试。这种写法在纯算法题里也许还能忍，但在Web赛里，可维护性直接决定你能不能做完试题中更复杂的功能模块。用数组方法组成的管道，每一层的输入输出都很清晰，出错时只要断点看中间结果就行。

还有一个实用技巧：把核心数据处理函数单独抽出来，放在文件底部或单独模块里，事件绑定和渲染都只调用这个函数。这样调试时可以直接在浏览器控制台调用getVisibleProducts()，想试什么参数就试什么参数，整个数据处理流程对你完全透明。

6. 考前突击清单与易错点自查表

6.1 把高频方法背成一张条件反射表

比赛时间紧张，你不能在考场上才想"咦，这个方法是修改原数组还是不修改"。所以我把最常用的方法整理成一张表，建议考前抄一遍、每天默写一遍。

这张表里"是否修改原数组"那一列是最容易混淆的。考试时如果拿不准，就采用一个安全原则：先拷贝再操作，[...arr] 能解决绝大部分原地修改带来的麻烦。

6.2 四个比赛中极易丢分的细节

第一个细节是返回值混乱。map、filter正常使用会返回新数组，但如果你在回调里用了花括号却漏写return，就变成返回undefined。forEach返回undefined本来正常，但如果你把它当map用，想拿到处理后的数组，结果自然是undefined。比赛里这种"看起来执行了但结果不对"的bug最难查，建议写完马上在控制台跑一遍，确认返回值的结构。

第二个细节是可变方法的使用顺序。sort和splice会修改原数组，如果你在筛选管道里把sort放在filter前面，排序会直接影响后续步骤读取的数据。我的习惯是让数据流保持单向：拷贝、筛选、排序、切片，每一步都不回头操作原始数据。

第三个细节是边界条件。空数组在every下恒为true，在some下恒为false；findIndex没找到返回-1；slice的end参数越界时自动截到末尾。这些边界行为平时开发无所谓，但在比赛里有对应的测试用例，写漏了就是满分和零分之间的差距。

第四个细节是includes和indexOf的适用场景。判断数组是否包含某个原始值（字符串、数字）用includes，代码更短更清晰；如果需要拿到下标再用indexOf；如果是对象数组，includes永远无法命中，必须用find或some。

6.3 最后一周的刷题建议

临近比赛那几天，不建议再去看各种偏门方法了。把上面这张表里的方法每个都写一个最小可运行示例，然后找两三套历年真题，专门练"把需求翻译成数组方法管道"这个动作。你可以给自己限定时间：看到一道数据处理题，5分钟内不动键盘，先写出伪代码——用哪些方法、先后顺序是什么。这个思路上的训练比多写几行代码更有价值，因为比赛里真正拉开差距的不是手速，而是你把需求转成方法链条的速度。

我自己最后一次模拟的时候，把所有数组方法写在一张便签纸上贴屏幕边，做完一道题就检查一遍哪些方法用顺手了、哪些还在犹豫。到第二周基本不需要看便签了，因为核心方法翻来覆去就是那十几个。把它们练成肌肉记忆之后，比赛里最爽的时刻就是看到"筛选+排序+分页"这类需求时，脑子里已经自动浮现出那四行链式调用。备赛的收获其实不止一张奖状——当你用数组方法把一堆逻辑理得清清楚楚的时候，你对"用代码解决问题"这件事的信心，也在跟着涨。