在 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 或扩展运算符，能让你的代码更简洁、更健壮，也更能跟上语言发展的步伐。
