JavaScript数组移除元素：从索引过滤到不可变数据的完整实践

把数组里“每隔一个元素删除一个”，题目名还写着 Removing Elements，Level easy。这类题我见过很多人几十秒写完就提交，觉得自己稳了，实际上里面藏着好几个容易让人栽跟头的点，而且这些点不是算法难度问题，是你对数组操作语义有没有真搞明白的问题。

先交代一下背景：这道题常见于各类在线刷题平台，输入一个数组，期望输出一个新数组，新数组里面保留原数组的第 0 个、第 2 个、第 4 个……也就是所有偶数索引位置的元素，奇数索引位置的元素不要了。光看这句话确实 easy，但我后来拿这道题试过几个刚入门的朋友，发现至少有三种写法跑出来结果是错的，而且错得还都挺隐蔽。所以这篇文章不是来教你怎么把题目 AC 掉，而是想借这个看似简单的场景，把数组遍历、索引变化、过滤语义、原地修改和不可变数据这些概念一次性捋清楚。

1. 题干复盘：先弄明白“每隔一个移除”到底在说什么

1.1 输入输出约定

先看一个最直观的例子。假设输入数组是：

javascript复制const people = ["Zhang", "Li", "Wang", "Zhao", "Qian", "Sun"];

期望输出：

javascript复制["Zhang", "Wang", "Qian"]

也就是说索引 0、2、4 被保留，索引 1、3、5 被移除。英文描述里的 “remove every second element” 经常被误解成“移除第二个元素、第四个元素……”，这个理解其实是正确的，every second element 并不是说“每两个保留一个”或者“把第二个以后的元素都留着”，而是指“每隔一个元素，拿走下一个”。

我做这道题的时候习惯先把测试用例固定下来，避免自己写着写着把语义弄反。最值得写进测试的几组用例是这样的：

最后两组特别容易踩坑。一组是关于 falsy 值，一组是关于奇数长度数组。后面我会专门说为什么这两组最容易让新手翻车。

1.2 “删除”这个动词容易误导人

我看到很多第一次写这道题的人，目光会死死盯住“Remove”这个词，接着第一反应就是：那我用 splice 把不要的元素从原数组里删掉不就行了？

思路本身没有错，但这里有一个细节容易被忽略：题目虽然叫 Removing Elements，但绝大多数版本的题干都要求你 return 一个新数组，原数组不应该被改动。也就是说，你要做的是“筛选并复制出需要保留的部分”，而不是真的在原数组上做删除。

这个区别非常关键。用 filter 或用循环加 push，你会天然生成一个新数组，原数组纹丝不动；用 splice 去原地删，要么你小心翼翼控制索引，要么就得先复制一份再删，否则就把原数据破坏了。实际工程里，函数对外暴露时是否修改入参，是会写进接口文档的约定，很多隐蔽 bug 都来自函数内部偷偷改了调用方还在用的数组。

1.3 索引条件是什么

如果你理解了这道题的关键不在于“删”，而在于“保留哪些”，核心逻辑就变成了一句特别简单的话：

只保留索引能被 2 整除的元素。

对应代码语言的表达就是 index % 2 === 0。想明白这一点的人，会用 filter 几秒钟写出来：

javascript复制const removeEveryOther = (arr) => arr.filter((_, index) => index % 2 === 0);

而没想明白的人，容易先去想“我要删除索引 1、3、5……”，然后陷入各种索引动态变化的泥潭。从写代码的经验来说，凡是能用“保留”来表达的过滤逻辑，尽量不要用“删除”来反向实现。人的脑子在处理“保留所有满足条件的东西”时，比处理“删掉所有不满足条件的东西”要可靠得多，尤其当条件还牵扯到位置关系时。

2. 一题多解：从最直白的循环到一行 filter

同一个需求，不同阶段的人会写出完全不同的代码。我不打算只给一个标准答案，而是把这几种解法都摆出来对比一下，重点讲清楚每一种背后的代价和适用场景。

2.1 最不容易错的基础循环

如果你刚开始学数组，我建议先从最笨的 for 循环写起：

javascript复制function removeEveryOther(arr) {
  const result = [];
  for (let i = 0; i < arr.length; i += 2) {
    result.push(arr[i]);
  }
  return result;
}

这段代码的关键在于 i += 2。它让循环直接跳着访问索引 0、2、4……，每次访问到的就是要保留的那个元素。既然只需要偶数索引，你就完全不需要访问那些要被移除的位置，也就不存在“删掉之后索引会不会变”的问题。

这个方法的时间复杂度是 O(n)，空间复杂度是 O(n/2)，也就是 O(n)。虽然要新建一个数组，但每个元素只被访问一次，没有任何多余的移动操作，这在所有解法里性能都算最优级别。它唯一的缺点是看起来不够“高级”，代码多一些，但可读性非常高，就算三个月后回来看，你也能一眼读懂它在做什么。

2.2 推荐写法：filter 按索引过滤

如果你已经熟悉数组的高阶方法，filter 是最贴合这个场景的：

javascript复制const removeEveryOther = (arr) => arr.filter((_, index) => index % 2 === 0);

filter 的语义就是“遍历数组，把符合条件的元素收集到一个新数组里”。这里通过第二个参数 index 判断位置，至于元素本身的值叫什么不重要，所以参数名用 _ 表示“我不关心值是什么，我只看索引”。

这里我要强调一个容易忽略的背后逻辑：filter 回调里的第一个参数是元素，不是索引。很多人刚学时会把回调参数名写成 item，然后下意识去 item % 2 === 0 判断能不能保留，这其实是错的。除非你确信这个数组里的每一项都是数字，并且你要判断的是数值本身的奇偶，否则你拿元素值去做位置筛选，得到的结果完全是另一回事。为了让自己不犯这种错，见到这类“按位置挑元素”的题目，直接写 (_, index) 这种形式，从命名上就切断你对 item 的注意力。

2.3 reduce 和生成器：能写，但要想清楚为什么写

reduce 也可以实现同样的逻辑：

javascript复制const removeEveryOther = (arr) =>
  arr.reduce((acc, item, index) => {
    if (index % 2 === 0) {
      acc.push(item);
    }
    return acc;
  }, []);

这段代码能跑，结果也对，但我个人不太推荐你用 reduce 去解这种题。理由是 reduce 本身擅长的是“把数组归约成一个值”，比如求和、拼接字符串、计算总数。这里你只是想把数组过滤一遍，如果用 reduce，你实际上是在手动模拟 filter 的职责，代码变长不说，语义反而不够直接。写代码时选择工具，第一原则是让意图最明显，而不是让写法看起来更有技巧。

如果你对生成器感兴趣，还可以借助 Array.from 配合索引映射来写：

javascript复制const removeEveryOther = (arr) =>
  Array.from({ length: Math.ceil(arr.length / 2) }, (_, i) => arr[i * 2]);

Math.ceil(arr.length / 2) 算出来是新数组应该有多长，比如长度为 7 的数组会保留 4 个元素。然后 arr[i * 2] 负责把新数组的第 0 位对应原数组索引 0，第 1 位对应原数组索引 2，第 2 位对应原数组索引 4。这个写法非常巧妙，但理解成本略高，适合在你想拓宽思路的时候玩一玩。真要写进业务代码里，我反而觉得有点炫技了。

2.4 其他语言怎么表达这件事

算法题的乐趣之一，是同样一个逻辑在不同语言里有完全不同的表达方式，对比一下能帮你更好地理解语言设计者的取舍。

Python 里这个需求只需要一行切片：

python复制def remove_every_other(arr):
    return arr[::2]

arr[::2] 的含义是从头开始，每隔 2 个取一个。这个语法糖非常直观，而且在 Python 社区里属于基础常识。切片操作还会自动处理空数组和奇数长度数组，不需要额外判断。

Go 语言没有内置的 filter 泛型方法（在 Go 1.21 之前），用最直白的循环：

go复制func removeEveryOther(arr []string) []string {
    result := make([]string, 0, (len(arr)+1)/2)
    for i := 0; i < len(arr); i += 2 {
        result = append(result, arr[i])
    }
    return result
}

注意我在 make 时给了容量 (len(arr)+1)/2，这算一个小优化，可以让 append 过程中不频繁扩容。对于这种明确知道结果长度的场景，预分配容量是个好习惯，尤其是原始数组上十万级别的时候，能省掉不少内存分配开销。

3. 提交之后才发现的三个隐藏雷区

3.1 用 filter(item => item) 会误删 falsy 值

我见过不止一个人写出这样看似简洁的代码：

javascript复制const removeEveryOther = (arr) => arr.filter((item) => item);

他本意可能是想表达“把没有值的元素丢掉”，或者单纯想简化参数，觉得反正不需要用到值。但这段代码的实际行为是：filter 会把所有 falsy 值都过滤掉。JavaScript 里的 0、false、""、null、undefined、NaN 都属于 falsy，一旦它们出现在偶数索引位置，它们也会一并被丢掉。

举个例子：

javascript复制const input = [0, "hello", false, "world", "", "!"];
const result = input.filter((item) => item);

你期望保留索引 0、2、4，也就是 [0, false, ""]，但实际上 filter 的回调返回的是元素本身，而元素本身是 falsy 时，就会被当成“不保留”，所以实际输出变成了 ["hello", "world", "!"]。这个错误在输入恰好都是字符串时完全看不出来，一旦数据里混入数字 0 或空字符串，结果立刻变得莫名其妙。

正确做法是永远不要用元素真值去决定保留与否，而是用索引：

javascript复制const input = [0, "hello", false, "world", "", "!"];
const result = input.filter((_, index) => index % 2 === 0);
// 输出 [0, false, ""]

这道题给我的教训是：过滤条件写在哪个维度上，就要用哪个维度的参数来判断。题目要的是位置关系，那判断条件就应该是 index；如果题目要的是元素本身的某些特征，才应该用元素值来过滤。

3.2 原地 splice 的索引漂移

再来看一种非常经典的错误。有人觉得用 splice 更直接，写出了下面的代码：

javascript复制function removeEveryOther(arr) {
  for (let i = 1; i < arr.length; i += 2) {
    arr.splice(i, 1);
  }
  return arr;
}

思路听起来没什么问题：索引 1 删掉，索引 3 删掉，索引 5 删掉，不就做到了吗？

问题出在 splice 一旦执行，数组会立刻发生变化，后面的元素会整体往前移动一位。你删掉了原来索引 1 的元素，原索引 2 的元素会跑到索引 1，原索引 3 的元素会跑到索引 2。此时你的循环变量带着 i += 2 走到 i = 3，你删除的其实是当前数组里的第 3 个位置，也就是原数组里的第 4 个元素，原本应该被删的“第 3、第 5 个元素”反而被跳过去了。

我用一组数据来模拟这个过程：

javascript复制// 原始数组
["A", "B", "C", "D", "E", "F"]

// i = 1，删除索引 1，也就是 "B"
["A", "C", "D", "E", "F"]

// i = 3，删除索引 3，也就是 "E"
["A", "C", "D", "F"]

最终输出变成了 ["A", "C", "D", "F"]，这显然不对。正确结果应该是 ["A", "C", "E"]。

如果你非要原地用 splice，最稳妥的办法是从后往前遍历。删除后面的元素不会影响前面元素的索引：

javascript复制function removeEveryOther(arr) {
  for (let i = arr.length - 1; i >= 0; i--) {
    if (i % 2 === 1) {
      arr.splice(i, 1);
    }
  }
  return arr;
}

从后往前删，你可以放心大胆地按原索引判断，因为每一次删除都发生在当前索引的右侧，左侧元素的索引不会发生任何变化。

但就算这个方法逻辑正确，我也要注意提醒你：它在性能上是不如生成新数组的。splice 删除一个元素后，需要把后面所有元素往前搬，虽然这里只删除一半元素，但总搬迁次数会达到 O(n²) 级别。当数组长度达到几万甚至几十万时，这个差距会非常明显。

所以我的结论是：能用 filter 或循环生成新数组，就尽量不要原地 splice。这不仅是代码风格问题，更是性能和副作用控制的问题。

3.3 稀疏数组和超长数组带来的意外

最后一个雷区来自数组本身的特殊性。

先看稀疏数组。JavaScript 里你可以这样创建一个有“空洞”的数组：

javascript复制const sparse = ["a", , "c", , "e"];

中间的逗号之间没有值，数组长度是 5，但索引 1 和 3 是空位（empty），不是 undefined，也没有实际元素。如果你用 for 循环访问 sparse[1]，你会得到 undefined，看起来好像访问到了；如果你用 filter，事情就有意思了——filter 会跳过稀疏数组中的空位，保持新数组也是稀疏的：

javascript复制const result = sparse.filter((_, index) => index % 2 === 0);
console.log(result); // ["a", "c", "e"]，不再是稀疏数组

等一下，实际上 filter 会跳过空位，所以回调根本不会对索引 1 和 3 执行，但它仍然会输出索引 0、2、4 这三个元素，看起来结果是连续的。这个行为并不影响本题的最终答案，但如果你在代码里依赖“回调被每个索引调用一次”这个假设，就会出错。比如你试图在 filter 之外再维护一个计数器，计数器会因为空位而少走几次，后续逻辑就乱了。

还有一种情况是大数组。假设输入数组有一百万个元素，filter 会创建一个全新的数组，把所有偶数索引的元素放进去。这在大多数场景下没有任何问题，因为结果数组本身就是题目要求的产物。但如果有人希望尽量减少内存峰值，循环 + 预分配容量的方式会比 filter 更可控。当然，这种优化属于锦上添花，而不是这道题的重点。

4. 从题目到业务：一次轮询名单误删的复盘

4.1 一个真实的轮询场景

单纯刷题可能感受不到这个逻辑有多常出现，我来讲一个我实际遇到过、并且踩了坑的业务场景。

当时要做一个轮询名单的漏斗筛选：有一批参与人名单，每一轮需要剔除一半参与人，剔除规则是“保留名单里的第 1 个、第 3 个、第 5 个……”，也就是说每隔一个去掉一个，留下来的进入下一轮。这个需求本质上就是 Removing Elements。

我一开始图省事，直接在自己的代码里用了一个看起来很合理的原地删除循环：

javascript复制const participantList = ["u001", "u002", "u003", "u004", "u005", "u006", "u007", "u008", "u009"];

for (let i = 1; i < participantList.length; i += 2) {
  participantList.splice(i, 1);
}

console.log(participantList);

你猜结果是什么？我跑了一下，得到名单变成了 ["u001", "u003", "u004", "u006", "u007", "u009"]。我期望保留 5 个人，结果等于保留了 6 个人，而且名单的分布非常诡异，有些人是连着的，有些人被跳过了。

这就是我前面说的索引漂移问题。splice 删掉一个元素后，后面所有人的下标都往前挪了一位，可我的循环还以为自己在处理原始下标，跳着删除，结果就删乱了。

4.2 用不可变操作代替原地删除

后来我把实现改成了不可变过滤，一劳永逸地解决了这个问题：

javascript复制const participantList = ["u001", "u002", "u003", "u004", "u005", "u006", "u007", "u008", "u009"];

const nextRoundList = participantList.filter((_, index) => index % 2 === 0);

console.log(nextRoundList);
// ["u001", "u003", "u005", "u007", "u009"]

这段代码完全没有去碰原来那个数组，也不会受到“删除之后索引变化”的干扰。你只管描述“我要保留哪些位置”，剩下的由 filter 负责。

那次复盘之后我给自己定了一个规矩：只要过滤逻辑是纯函数式的“按条件筛选”，一律先考虑 filter；只有当你确实需要修改原数组，并且已经确认没有其他地方引用它时，才考虑原地删除。这个规矩让我后来少踩了很多类似的坑。

4.3 更泛化的“保留第 N 个”工具

那道题只是“每隔一个保留一个”，但你很容易遇到更复杂的需求，比如每 5 个里保留第 2 个？或者每 10 个里保留第 7 个？

这时候可以把逻辑抽成一个通用函数：

javascript复制function keepEveryNth(arr, step, offset = 0) {
  return arr.filter((_, index) => {
    return (index - offset) % step === 0;
  });
}

step 表示每隔几个取一个，offset 表示从哪个位置开始算第一个。拿这道题来说，就是 keepEveryNth(arr, 2, 0)。

真实业务里这种泛化函数用处很大。比如你要对一批日志做降采样，每 100 条保留 1 条用于抽样分析；或者你有一个任务列表，要分给两个消费者，单号任务走 A 队列、双号任务走 B 队列，本质上都是在“按索引位置做筛选”。这类需求一旦写成通用工具，后续只要传参就能复用，不用每次重新推导索引关系。

4.4 原数组到底需不需要保留

遇到轮询名单这种场景，默认做法是新数组返回，旧数组留在原处。但如果业务明确要求原数组也要更新，你有两个选择：一是过滤后重新赋值，比如：

javascript复制let participantList = ["u001", "u002", "u003", "u004", "u005"];
participantList = participantList.filter((_, index) => index % 2 === 0);

二是复制一份再原地删除。最省事的还是第一种，因为赋值操作本身就把旧引用替换掉了，外部其他变量如果还在引用旧数组，它们收到的是旧数据；只有通过这个变量再次访问时，才会拿到筛选后的结果。这种语义在工程里非常清晰，不会出现某个函数在背后偷偷修改共享数组导致调用方数据错乱的问题。

5. 把这道题彻底吃透后，我建议你再问自己几个问题

5.1 性能层面：filter 会不会很浪费

有人会担心 filter 对整个数组做一次完整遍历，效率是不是太低。这个问题要分场景看。对于这种“每隔一个保留一个”的场景，你无论如何都要访问一遍原数组才能决定去留，所以时间复杂度下限就是 O(n)，filter 并没有增加额外的复杂度。它唯一的额外开销是一次新数组的创建和填充，但这份开销是结果本身需要的，不是浪费。

如果真的到了不能忍受额外内存的极端场景（例如处理超大数组或者内存受限环境），你可以考虑使用生成器来逐个产出结果，避免一次把所有结果堆积在内存里。但这种优化并不适合所有场景，因为消费者往往最终还是要拿到完整列表。在没有明确性能瓶颈之前，不要为了“可能的优化”牺牲代码可读性。

5.2 语义层面：为什么答案这么短

这道题最有趣的体验可能是：在你理解了核心逻辑以后，答案短得不像话，一行 filter 就结束了。很多人会因此怀疑自己是不是漏了什么。

我想说的是，短不等于简单。短代码背后需要对数组方法、回调参数、索引语义都有准确的认知。反过来，写得很长的代码也不一定更稳，很多长代码只是把简单逻辑绕复杂了。真正重要的是你在面对题目时，能准确描述出“我要保留的是什么”，然后选择最直接的手段去表达它。

5.3 思考层面：如果保留的不是每隔一个，而是每隔三个

把题目稍微改一下，不要每隔一个取一个，而是每 3 个保留第 1 个，你会写吗？如果你已经理解了 index % step === 0 这个模式，你会发现不过就是把除以 2 改成除以 3。这说明算法题的核心不是背答案，而是找到“筛选条件”和下标的映射关系。

我后来带人练题时，经常会在这道题之后追加几个变体，比如：

• 保留最后一个元素怎么办；
• 从索引 1 开始保留，每隔一个取一个怎么办；
• 数组长度特别大时你怎么验证结果正确。

这些追加问题比原题本身更能体现一个人的基本功。如果能把这道题背后的索引变换、原地修改、不可变数据这几个概念讲清楚，即使代码只有一行，我也认为你是真的会了。

我自己刷题多年，慢慢发现一个规律：easy 题的价值不在于难倒你，而在于用最少的背景知识，把语言本身最常见的坑展示出来。Removing Elements 恰好就是这样一道题，它让我在后来写所有过滤逻辑时都会下意识确认三件事：我的过滤条件是值还是索引；我有没有改动原数组；空数组和 falsy 值会不会让结果失真。想清楚这三件事，比多背三五十个 API 有用得多。