柯里化是用闭包将“变的”与“不变的”分离，固化配置项（如base url、locale）、延迟注入执行参数，实现逻辑复用与场景适配；其本质是参数固化+延迟执行，依赖闭包维持独立作用域以安全保存配置。
柯里化不是把函数拆着玩，而是用闭包把“变的”和“不变的”稳稳分开——配置项提前固化，执行逻辑延后注入，让同一段控制代码能适配不同场景。
配置项怎么才算“预处理”到位？
真正的预处理，是让后续调用完全绕过重复设置，只聚焦业务输入。比如 API 请求中 base URL、认证头、超时时间这些不变要素，应在首层调用就锁死，后面只传路径和数据。
- 错误做法：每次调用都写
fetch('/api/users', { headers: auth, timeout: 5000 }) - 正确做法：先
const api = createApi({ baseUrl: '/api', headers: auth, timeout: 5000 })，再api.get('users')或api.post('orders', data)
闭包在这里干了什么？
它不是临时记个变量，而是为每次预处理创建独立作用域，把配置项安全封存其中。这个作用域不会随调用结束销毁，直到整个柯里化链完成执行。
- 每个
createApi(config)调用，都生成一个新闭包，里面存着专属的config - 返回的
api.get函数，始终能读取自己闭包里的baseUrl和headers，不依赖外部状态 - 多个实例（如
userApi和orderApi）互不干扰，各自持有不同配置
哪些配置适合这样预处理？
核心判断标准：是否在多个调用中保持稳定、是否属于策略层而非数据层。
- 适合：主题色、语言 locale、节流延迟值、校验规则、图表尺寸、日志级别
- 不适合：用户 ID、表单值、时间戳、动态 token（除非 token 在整个会话周期内不变）
- 边界情况：token 若短期有效，可结合闭包 + 刷新机制，但需显式管理生命周期，不能靠闭包自动更新
写的时候注意什么？
别让“预处理”变成“预埋陷阱”。重点盯住三点：
- 配置值大小：大对象或长数组被闭包长期持有，可能引发内存累积，尤其在高频创建场景（如每行表格生成一个柯里化函数）
- this 绑定：如果原函数依赖 this（如类方法），柯里化后需手动
.bind()或改用箭头函数包装 - 参数数量判断：别只信
fn.length，带默认值或 rest 参数的函数会失准，建议配合运行时参数收集逻辑
