柯里化本质是拆解参数传递时机而非参数本身，用于解耦执行时机与参数供给，在React事件绑定、Redux异步Thunk、Vue响应式调度及工具库中实现配置固化、逻辑复用与性能优化。
在框架源码中理解柯里化，关键不是背定义，而是看它“在哪被用、为什么非用不可、不用会怎样”。它往往藏在配置封装、逻辑复用和接口解耦的缝隙里，不显山不露水，但一抽走就崩。
React 中的事件处理器预置
React 官方文档推荐写法：onClick={() => handleClick(id)}，但频繁渲染时会创建新函数。真实源码（如 React DOM reconciler）内部对事件绑定做轻量柯里化处理：
- 把
dispatchEvent这类底层函数提前固化事件类型、目标节点等上下文 - 暴露给组件层的
onClick实际是柯里化后只等「用户动作数据」的函数 - 避免每次 render 都重新闭包整个事件逻辑，提升 diff 效率
Redux Toolkit 的 createAsyncThunk
这个 API 表面是语法糖，底层大量依赖柯里化链：
-
createAsyncThunk('users/fetch', async (arg, thunkAPI) => {...})—— 第一层固化 action type 和异步逻辑 - 返回的 thunk 函数本身是柯里化结构：
(arg) => (thunkAPI) => Promise - 实际 dispatch 时传入
dispatch(fetchUser(123))，123 被缓存在闭包中，后续自动注入 store 状态、dispatch 方法等
Vue 3 响应式系统中的 effect 调度
在 reactive 和 effect 的交互中，trigger 触发更新时，并非直接执行所有副作用，而是：
立即学习“Java免费学习笔记（深入）”；
- 先用柯里化方式把「触发类型（set/delete）」「key」「新旧值」等参数分阶段收集
- 构造出一个带上下文的 runner 函数，再交由 scheduler 排队
- 这样同一个 effect 可以被不同 key 的变更复用，而无需为每个字段单独注册监听器
Lodash 或 Ramda 的工具链设计
虽然不算框架源码，但它们是框架作者常借鉴的范式：
-
R.filter(R.gt(10))——R.gt是柯里化函数，R.gt(10)返回「判断是否大于10」的断言函数 - 框架内部做数据转换（比如 Ant Design Table 的
filters处理）时，会悄悄复用这类模式：固定比较规则，动态传入字段值 - 本质是把「配置」变成「可执行逻辑」，比写一堆 if-else 或 switch 更易测试和组合
看源码时，盯住三个信号：函数返回函数、闭包变量长期持有、形参个数明显少于原始逻辑所需——那基本就是柯里化在干活。
