fn.length 不可靠，因其仅统计左侧连续无默认值的形参个数，遇默认值或 rest 参数即停止；应手动指定 arity、统一合并参数、交由原函数处理默认值与 rest。
JavaScript 函数柯里化处理可选参数（如默认值、rest 参数）时，不能依赖 fn.length 准确判断“需多少参数才执行”，因为该属性对含默认值或 rest 的函数会失真。例如 function foo(a, b = 1, c) {} 的 length 是 1，但实际至少需要传入 两个参数（a 和 c）才能合理运行——b 虽有默认值，但 c 没有，且位置靠后。
为什么 fn.length 不可靠
函数的 length 属性只统计**从左开始连续无默认值的形参个数**，遇到第一个带默认值的参数就停止计数，rest 参数（...args）也不计入。这导致：
- 含默认值的函数：柯里化可能过早触发执行，传入不足却已调用原函数
- 含 rest 参数的函数：
length忽略...rest，无法反映“剩余参数应被收集”的语义 - 箭头函数：
length恒为 0，直接失效
推荐的应对方式
不强行适配所有语法糖，而是采用更可控、语义清晰的策略：
-
手动指定期望参数个数（arity）：调用柯里化函数时显式传入目标参数数量，绕过
fn.length的歧义。例如curry(add, 3) - 合并参数时不区分“必填/可选”，统一累积：每次调用都把新参数追加到已存列表中，等用户主动调用时再交由原函数内部逻辑处理默认值和 rest
- 避免在柯里化层做参数有效性校验：让原函数自己决定哪些参数缺失时用默认值填补，柯里化只负责“传递”和“延迟”
-
对 rest 场景改用偏应用（partial）更自然：比如
function sum(...nums) {}更适合用partial(sum, [1, 2])固定前缀，而非强行拆成单参链
实际合并参数的操作要点
无论是否有默认值，参数合并始终使用数组拼接，保持顺序与调用节奏一致：
- 用
[...prevArgs, ...nextArgs]或prevArgs.concat(nextArgs)合并，不跳过、不重排 - 支持一次传多个值：如
curried(1, 2)(3)→ 先合并[1, 2]，再合并[3]得[1, 2, 3] - 执行时机交给原函数自身逻辑：即使
args.length ，只要用户调用了，就尝试 <code>fn(...args)；错误由原函数抛出，柯里化不拦截
本质上，柯里化不是“参数校验器”，而是“参数搬运工+执行调度器”。面对可选参数，关键是放弃对 length 的迷信，把控制权交还给函数定义者。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
