JS 里那个“万能”的 arguments，现在还能信吗？

写前端这些年，遇到过不少“历史遗留问题”。其中 arguments 对象绝对是元老级的存在。刚入行时，它是我们处理不定数量参数的救星，但如今新项目里，你如果还在大量使用它，可能会引来同事的侧目。今天咱们不背语法定义，只聊聊这东西在实际开发中的真实表现和避坑指南。

arguments 本质上是个伪数组。这意味着你在控制台看它长得像 [...]，也能通过索引访问元素，但千万别指望直接调用 .push() 或 .map()。如果你试过 arguments.map()，浏览器大概率会报 TypeError，因为它缺少数组的原型方法。最稳妥的处理方式，是把它转换成真正的数组，比如用 Array.from(arguments) 或者经典的 [].slice.call(arguments)。这种转换虽然基础，但在处理参数校验时非常关键。

很多人翻车的地方，往往出在箭头函数上。这是新语法带来的最大认知断层。普通函数中，arguments 指向当前执行上下文；但箭头函数压根没有属于自己的 arguments 对象，它会向上层作用域查找。如果你在一个箭头函数里打印 arguments，且外层没有非箭头函数包裹，你会得到未定义的报错。所以，当看到代码里混着箭头函数又出现 arguments 时，逻辑链大概率已经断了。新代码里处理不定参数，请无脑选择 rest 参数（...args），它不仅返回的是真数组，语义也更清晰。

性能方面也有讲究。在某些旧版本的 V8 引擎中，一旦函数内部使用了 arguments 对象，整个函数的优化可能会被降级。虽然现代引擎修复了不少问题，但这依然是一个隐形的性能瓶颈。特别是高频调用的工具函数，引入 arguments 可能让原本丝滑的执行多耗几毫秒。对于追求极致性能的库作者来说，这点必须权衡。

当然，说 arguments 完全没用也不客观。在维护老旧项目，尤其是那些基于原型链深度绑定的第三方库时，你可能被迫使用它。比如需要动态获取调用栈信息，或者某些特定的装饰器模式，arguments.callee（尽管已废弃）曾扮演过角色。但在新业务开发中，除非是为了兼容 IE 等古老环境，否则没必要刻意去碰它。

还有一个容易被忽视的细节：参数个数不等于 arguments.length。虽然通常两者一致，但如果你在函数内动态修改了形参，或者通过对象扩展传参，arguments 记录的是实际传入的数量。这种差异在处理重载逻辑时经常造成边界判断失误。

总结一下，arguments 就像工具箱里的老锤子，能干活，但太重且有锈迹。面对新的需求场景：

1. 优先使用展开运算符 ...args，获得标准数组能力。
2. 阅读源码遇到 arguments，需警惕箭头函数作用域陷阱。
3. 高频函数避免依赖 arguments，防止潜在的性能损耗。

技术更新迭代快，理解老机制是为了更好地维护过去，而掌握新语法则是为了构建更稳健的未来。下次写不定参数函数前，不妨再想想，是否真的需要这个“老伙计”出马。