识别数组原型slice.call老旧写法的现代替代

在 JavaScript 的演进历程中，我们时常会遇到一些“历史遗迹”。Array.prototype.slice.call(arguments) 便是其中之一。这行代码曾是 ES5 时代处理函数参数的标配，但如今，它更像是一个需要被识别并升级的遗留标记。如何判断它是否“老旧”？关键在于三点：它是否出现在传统函数中手动转换 arguments、是否使用了 .call() 方法来借用数组方法、以及整个上下文是否完全没有用到任何 ES6 及以上的现代语法特性。一旦满足这些条件，基本就可以考虑进行现代化重构了。

一眼识别老旧写法的特征

这类写法通常有固定的模式，识别起来并不困难：

• 函数体开头，常常能看到类似 const args = Array.prototype.slice.call(arguments) 或更简短的 [].slice.call(arguments) 这样的语句。
• 函数本身是使用 function 关键字声明的（而非箭头函数），并且内部依赖了 arguments 对象。
• 代码中找不到 ...（扩展运算符/剩余参数）、Array.from、for...of 等现代语法的踪影。
• 项目配置明明已经支持 ES2015+，但代码里依然保留着这种为了兼容 IE8 等老浏览器的写法。

最直接的现代替代：剩余参数（...args）

如果要评选一个最优雅、最彻底的替代方案，剩余参数（Rest Parameters）当之无愧。它不仅语义清晰——直接声明函数接收不定数量的参数，而且性能优异，最重要的是，得到的 args 本身就是一个真正的数组，无需任何额外转换。

• 改造前：function sum() { const args = Array.prototype.slice.call(arguments); ... }
• 改造后：function sum(...args) { /* args 直接就是数组，可以随意使用 map、filter、reduce 等方法 */ }
• 箭头函数同样完美支持：const sum = (...args) => args.reduce((a, b) => a + b, 0);

其他合理替代方案（按优先级）

当然，并非所有场景都能直接修改函数签名。例如，当你需要封装一个已有的函数，或者需要处理 arguments 之外的类数组对象（如 DOM 集合）时，剩余参数就无能为力了。这时，可以考虑以下方案：

• Array.from(arrayLike)：这是最安全、语义最明确的转换方法。它能处理各种边界情况，比如 length 属性为 undefined 的对象，并且支持将 NodeList、HTMLCollection，甚至 Map/Set 的键值对转换为数组。
• [...arrayLike]：扩展运算符写法非常简洁。但需要注意，它要求对象必须具有 Symbol.iterator（即可迭代）。在一些旧版本的 DOM 实现中，部分 HTMLCollection 可能不可迭代，直接使用扩展运算符会报错。
• 扩展运算符 + 数组字面量组合：对于日常的 DOM 操作，这通常是个轻量级的选择。例如，[...document.querySelectorAll('div')] 就能快速将 NodeList 转为数组，在大多数现代场景下已经足够好用。

为什么不该再用 slice.call？

平心而论，slice.call 本身并不是错误，它只是过时技术权衡下的产物。继续使用它会带来一些潜在问题：

• 适用范围窄：它只适用于那些拥有 length 属性和数字索引的“类数组”对象。对于 Set、Map 这类真正的可迭代对象，它就无能为力了。
• 行为难以预测：如果遇到 arguments.length 值为 NaN 的极端情况，它会静默地返回一个空数组，这种隐晦的行为不利于调试和维护。
• 与现代语法不兼容：在箭头函数中，arguments 对象不可用，因此这套写法会直接失效。
• 性能优势不再：现代 JavaScript 引擎（如 V8、SpiderMonkey）已经对 ... 和 Array.from 进行了深度优化，性能差距微乎其微。为了那一点点可能不存在的性能优势而牺牲代码的可读性和现代性，实在得不偿失。

总而言之，识别并替换掉 Array.prototype.slice.call(arguments) 这类老旧写法，是保持代码库健康、清晰和现代化的重要一步。优先使用剩余参数 ...args，在无法修改签名的场景下灵活选用 Array.from 或扩展运算符，能让你的代码更简洁、更健壮，也更能跟上语言发展的步伐。