柯里化处理带命名空间前缀的API，核心是分层固化环境、版本、模块前缀：第一层传baseURL，第二层传version，第三层传endpoint，自动拼接URL并支持注入认证与默认头，实现模块化复用。
用柯里化处理带命名空间前缀的 API，核心是把“固定前缀”提前锁住，后续调用只聚焦业务路径和参数，不重复写 baseURL 或版本号。
明确前缀层级，按语义分层固化
API 命名空间常含环境、版本、模块三类前缀，比如 https://api.prod.example.com/v2/user。柯里化适合按此顺序收参：
- 第一层传 baseURL（如
'https://api.prod.example.com'），隔离环境差异 - 第二层传 version（如
'v2'），避免每个接口硬编码/v2/xxx - 第三层才是具体 endpoint（如
'/user'），保持路径语义清晰
封装请求函数，让前缀自动拼接
不依赖字符串拼接或模板字面量，而是靠函数闭包记忆前缀。例如：
const createAPI = (baseUrl) => (version) => (endpoint) => (options = {}) => {const url = `${baseUrl}/${version}${endpoint}`;
return fetch(url, {
method: options.method || 'GET',
headers: { 'Content-Type': 'application/json', ...options.headers },
body: options.body && JSON.stringify(options.body)
});
};
这样就能生成专用实例：const prodV2 = createAPI('https://api.prod.example.com')('v2');const getUser = prodV2('/user');getUser({ method: 'GET', params: { id: 123 } });
配合认证与默认头，避免每次透传
前缀之外，Token、租户 ID、语言等也属于“半固定配置”。可叠加一层柯里化注入：
- 在 endpoint 层之后再加一层 authContext，比如
(authToken) => (options) => {...} - 或直接合并进第三层：让
prodV2('/user')(token)返回最终可调用函数 - 默认头（如
X-Tenant-ID）可在生成 endpoint 函数时一并固化，无需每次判断
模块化复用，不同前缀互不干扰
多个服务共用同一套逻辑，但前缀不同——这正是柯里化的天然优势：
const userAPI = createAPI('https://api.example.com')('v2');const paymentAPI = createAPI('https://pay.example.com')('v1');- 两者结构一致、类型兼容、测试方式统一，只是初始参数不同
- 不会像闭包那样把前缀写死在某个文件作用域里，导致难以跨模块共享
