柯里化通过闭包分步固定配置参数，每次调用累积至config对象，最终合并传入目标函数；支持手动触发执行，浅合并需注意嵌套覆盖，复杂场景需深合并。
柯里化本身不直接“组装配置项”，但它天然适合分步固定配置参数——通过闭包保存已传的配置片段，后续调用时再合并补充，最终一次性传给目标函数。关键在于把配置当作函数参数的一部分来处理，而不是额外对象。
用闭包记忆预设配置
每次柯里化调用都形成一个新闭包，里面能安全保存当前已传的配置项（比如 host、token、timeout）。这些值不会被后续调用覆盖，而是累积起来：
- 第一次调用传 { host: 'https://api.example.com' }，返回新函数，闭包记住这个 host
- 第二次传 { token: 'abc123' }，新函数在原有基础上追加 token，仍返回函数
- 最后一次传业务数据（如 { id: 123 }）或显式触发执行，才把所有配置 + 数据合并后交给 request 函数
支持对象参数的柯里化写法
原生 fn.length 只认形参个数，对对象解构无效。所以实际中更常用“手动累积 + 显式执行”模式：
- 不依赖 fn.length 判断，改用是否传入最终数据或是否调用 .done()/.exec() 等方法来触发
- 内部维护一个 config 对象，每次调用都 Object.assign 合并新配置
- 返回的函数既可继续接收配置，也可接收业务参数，逻辑由调用方式决定
典型配置组装示例
比如封装一个请求构造器：
const api = curryConfig((config, data) => {fetch(config.url, { method: config.method, headers: { Authorization: config.token }, body: JSON.stringify(data) });
});
const userApi = api({ url: '/users', method: 'POST' });
const authUserApi = userApi({ token: 'xyz' });
authUserApi({ name: 'Alice', email: 'a@b.c' });
这里每一步都在往 config 上叠加字段，最后一步传 data 才真正发起请求。
注意配置覆盖与合并策略
纯 Object.assign 是浅合并，嵌套配置（如 headers）会被整个替换。如需深合并，得手动处理或引入工具函数：
- 简单场景：约定配置结构扁平，避免嵌套冲突
- 复杂场景：在累积 config 时用深拷贝+深合并，比如用 structuredClone + 自定义 merge 工具
- 避免副作用：每次合并都生成新对象，不修改原始配置引用
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
