柯里化是将多参数函数转换为一系列单参数函数的过程，核心是参数逐步固化与延迟求值，需明确参数个数、延迟执行、保持this绑定，避免与部分应用混淆。
什么是柯里化，别被概念绕晕
柯里化不是魔法，只是把一个接收多个参数的函数，变成一系列每次只接收一个参数的函数。比如 add(1, 2, 3) 变成 add(1)(2)(3)。关键不在“多层括号”，而在“参数逐步固化、延迟求值”。很多人一上来就写递归闭包，结果边界没处理好，undefined 或 NaN 频出，根源是混淆了“柯里化”和“部分应用”——前者严格固定参数数量，后者更灵活。
手写柯里化函数的三个必守底线
自己实现时，避开这三点，80% 的坑就绕开了：
-
明确原函数的期望参数个数（length）：用
fn.length获取形参个数，别靠传入参数长度判断，否则箭头函数、含默认值或剩余参数的函数会误判 -
只在参数收齐时才真正执行：中间步骤必须返回函数，不能提前调用；哪怕传入
undefined或null，只要没凑够数，就继续等待 -
保持 this 和原始上下文一致：用
fn.apply(this, args)而非fn(...args)，避免丢失调用时的 this 绑定（尤其在对象方法中使用时）
常见翻车场景与对应解法
这些不是理论问题，是真实调试半小时才发现的硬伤：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
-
遇到有默认参数的函数（如
function foo(a, b = 10, c)）：fn.length返回 2（只计算无默认值的参数），但实际可能需要传 3 个才能触发执行。解法：不依赖 length，改用显式指定参数数量的柯里化（如curry(fn, 3)） -
柯里化后用于事件监听或 Promise 链：返回的函数若没绑定 this，执行时 this 指向 window 或 undefined。解法：内部用
bind或箭头函数包裹，或要求调用方手动.bind(obj) -
重复柯里化同一函数导致闭包堆积：每次调用
curry(fn)都新建闭包。高频场景（如渲染循环）应缓存柯里化结果，而非每次都重新 curry
用 Lodash 或 Ramda？先看清它们的差异
直接用工具库省事，但得知道它们“怎么省”的：
-
Lodash 的
_.curry是“自适应柯里化”：它不严格按length执行，而是收到足够参数（≥ length）就运行，支持早返回；适合多数业务场景，但不符合纯柯里化定义 -
Ramda 的
R.curry更接近函数式语义：只在参数完全匹配时执行，且自动支持占位符（R.__），适合需要精确控制参数顺序的组合场景 - 注意副作用函数（如修改 DOM、发请求）不要盲目柯里化：柯里化本身不改变执行时机，只是包装。如果原函数有副作用，柯里化后仍会在最终调用时发生——别误以为“包装了就变安全了”
一句话总结防坑心法
柯里化不是炫技，是为组合与复用服务。写之前先问：这个函数是否会被多次、不同参数组合地调用？它的参数是否有自然的分组逻辑？如果没有明确意图，不如用普通函数或 partial。真正稳健的柯里化，是克制的封装，不是无脑套娃。
