call不适合处理不确定参数数量的场景，因其语法要求参数逐个列出，无法直接传入数组；应对动态参数应优先使用展开运算符（…）或apply，必要时可结合call与展开运算符实现。
call 本身不适合处理不确定参数数量的场景——它要求参数逐个列出，没法直接传数组。真要应对参数个数不固定的情况，得换思路或搭配其他方法。
为什么 call 不适合动态参数
call 的设计就是为已知参数个数服务的。语法是 fn.call(thisArg, arg1, arg2, arg3...)，每个实参都得单独写出来。如果参数来自数组或 arguments，就得手动展开，代码冗长还容易出错。
- 比如有个数组
args = ['Hi', 'Alice', '!']，用 call 就得写成greet.call(obj, args[0], args[1], args[2]) - 数组长度一变，这行就得改；要是长度未知，根本没法硬写
- arguments 这类类数组对象更麻烦，不能直接索引到末尾，还得先判断 length
替代方案：用 apply 更直接
当参数已经组织成数组或类数组（如 arguments、NodeList），apply 是更自然的选择。它专为“把一整包参数摊开调用”而生。
-
Math.max.apply(null, [3, 7, 1])→ 等价于Math.max(3, 7, 1) -
Array.prototype.slice.call(arguments)可换成Array.prototype.slice.apply(arguments)（虽不常用，但合法） - 构造函数实例化时，
new Person(...args)（ES6+）比Person.apply(obj, args)更简洁，但 apply 在旧环境仍是刚需
现代写法：优先用展开运算符（…）
ES6 起，…args 完全替代了 apply 在多数场景的作用，写法更直观、语义更清晰。
-
greet(...args)直接展开数组调用，无需指定 this？那就用箭头函数或提前绑定 - 需要指定 this 时，可结合 call 与展开：
greet.call(obj, ...args)—— 这才是 call 处理动态参数的正确姿势 - 注意：… 不能用于类数组对象（如 arguments），仍需先转数组，而 apply 可直接受
特殊情况：call + 参数预处理
极少数必须用 call 且参数动态时，可通过拼接参数列表实现，但应谨慎使用。
- 例如封装一个兼容函数：
function safeCall(fn, thisArg, args) { return fn.call(thisArg, ...args); } - 避免用 eval 或 Function 构造器拼字符串，既不安全也不必要
- 若逻辑复杂，建议重构为接收数组参数的函数，而非强行适配 call
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
