只需一份OpenAPI文档，openapi-ts-request即可自动生成uni-app兼容的TypeScript类型、请求函数、枚举及Mock服务；关键在于封装符合要求的uni.request函数并配置指向。
不用手写 uni.request、不用手动补类型、不用反复核对字段名——只要有一份标准的 OpenAPI/Swagger/Apifox 文档，就能全自动产出 TypeScript 类型 + 请求函数 + 枚举 + Mock 服务。
用 openapi-ts-request 生成 uni-app 兼容的请求层
它不是 axios 专用工具，而是支持自定义请求入口的通用生成器。关键在于把 uni.request 封装成符合其调用约定的函数，并在配置中指向它。
- 先安装：
pnpm add -D openapi-ts-request（或 npm/yarn） - 在项目根目录新建
openapi-ts-request.config.ts，内容必须返回一个数组，每个对象对应一个 API 服务：
import type { GenerateServiceProps } from 'openapi-ts-request';
export default [
{
schemaPath: 'https://your-api.com/openapi.json',
outputDir: './src/api/user',
requestLibPath: '@/utils/request.ts', // ← 指向你封装好的 uni.request 函数
enumMode: 'asConst', // 生成 const enum 更安全
}
] as GenerateServiceProps[];
生成后，./src/api/user 下会自动出现 index.ts（含所有接口函数）、types.ts（含响应/请求体类型）、enums.ts（含枚举）。
request.ts 封装必须满足两个条件
openapi-ts-request 要求你提供的 requestLibPath 导出一个默认函数，该函数签名需兼容其内部调用逻辑：接收 url、method、data、params、headers，并返回 Promise。
- 不能直接用
uni.request，因为它不接受params对象作为查询参数，需手动拼接 - 不能忽略
data和params的区分：POST/PUT 用data，GET/DELETE 用params - 建议统一处理 loading、token、错误 toast，这些逻辑写在封装层，生成代码里就干净了
一个最小可用示例：
import type { RequestOptions } from 'openapi-ts-request';
export default function request(options: RequestOptions) {
const { url, method = 'GET', data, params, headers = {} } = options;
// GET/DELETE 拼 query
const finalUrl = method.toUpperCase() === 'GET' || method.toUpperCase() === 'DELETE'
? `${url}${params ? '?' + new URLSearchParams(params).toString() : ''}`
: url;
return new Promise((resolve, reject) => {
uni.request({
url: finalUrl,
method,
data: method.toUpperCase() === 'GET' || method.toUpperCase() === 'DELETE' ? undefined : data,
header: {
'Content-Type': 'application/json',
...headers,
},
success: (res) => {
if (res.statusCode >= 200 && res.statusCode < 300) {
resolve(res.data);
} else {
uni.showToast({ title: `请求失败 ${res.statusCode}`, icon: 'none' });
reject(res);
}
},
fail: (err) => reject(err),
});
});
}
生成后怎么用？注意三处坑
生成的代码是“即插即用”的，但实际接入时容易卡在三个地方：
-
import { getUserInfo } from '@/api/user'—— 路径别写错，outputDir决定导入路径 - 返回值类型是泛型，比如
getUserInfo<user>()</user>，不显式传User时，TS 推导可能不准确，建议始终显式标注 - 枚举字段名若含连字符（如
user-status），生成的 key 会被转成userStatus，但后端返回仍是user-status，此时需在types.ts中手动加@ts-ignore或改用as const模式配合映射表
另外，openapi-ts-request 不处理条件编译，如果某个接口只在 App 端可用，得自己在调用处加 #ifdef APP-PLUS，生成器不会帮你加。
比手写强在哪？真实对比点
一个含 12 个接口、47 个字段、6 个枚举的模块，手写类型+请求函数平均耗时 1.5 小时，且后续后端字段改名/删字段时，前端极易漏改；而用此方案：
- 首次生成：30 秒内完成
- 后端改了字段：重新运行命令，5 秒覆盖，类型报错立刻定位到哪一行
- 新增接口：只需更新文档，无需动前端一行逻辑代码
- 团队协作：所有人用同一份文档生成，彻底消灭“我本地跑得通，你那边报类型错误”
真正麻烦的从来不是生成动作本身，而是生成后的类型一致性校验和跨人协作时的预期对齐——这个环节，手工维护永远跑不赢自动化。
