TypeScript 如何做接口请求类型
平时我们用JavaScript写接口请求，经常会碰到“传了参数但类型不对”“接口返回的内容找不到属性”的坑，这些问题在多人协作项目里尤其闹心。而TypeScript（简称TS）的一大好处，就是能帮我们提前把这些类型问题拦在代码运行前，其中最常用的就是用TS的类型来规范接口请求，就像给接口请求写了“使用说明书”。
先搞懂：为什么要给接口请求设类型？
先举个生活里的例子：你点外卖时，会告诉商家“我要一份中份的糖醋排骨，不要辣，加米饭”，这就是你给商家的“请求规则”，商家按这个规则给你做餐，就不会出错。接口请求也是一样：前端给后端发请求，要明确说清“我要传什么参数（比如用户ID、商品数量）”，后端返回的内容也得有明确的样子。
JS里没有这个规则，比如你要传“年龄”，不小心传了个字符串“18岁”，后端要数字却接收到字符串，就会报错；或者你以为后端返回的内容里有“积分”属性，结果后端没做这个字段，代码运行才报错。而TS的类型，就是帮你提前把这些“规则”写清楚，写代码时就能被编辑器直接提示，不用等项目跑起来再找bug。
接口请求类型的核心：用“类型别名”或“接口”定义请求规则
TS里最常用的就是两种方式，都是用关键字type（类型别名）或interface（接口）来写，用法几乎一样，新手记一种就行，推荐用interface，更贴近“规则”的感觉。
举个最常见的例子：我们要做一个“提交用户注册信息”的接口，需要传三个参数：用户名（字符串）、年龄（数字）、是否同意协议（布尔值）。我们可以先定义一个RegisterRequest的接口，就像写这个请求的“格式单”：
`typescript
// 定义注册接口的请求参数规则
interface RegisterRequest {
username: string; // 用户名，必须是字符串
age: number; // 年龄，必须是数字
agreeProtocol: boolean; // 是否同意协议，必须是布尔值
}
`
这个接口的意思是：以后只要是这个注册请求，传的参数必须严格对应这三个字段，类型不能错，少了或多了都会报错。
把接口类型用在实际请求里：举个实战例子
平时我们用fetch或axios发请求，只要把定义好的接口套进去就行，完全不用改请求的逻辑，只是给参数和返回值“贴个标签”。
比如用axios发注册请求的代码，没加类型时是这样的：
`javascript
// 普通JS写法，没做类型校验
async function register(data) {
return axios.post('/api/register', data);
}
`
加了TS的接口类型后，变成这样：
`typescript
// 先写好接口规则
interface RegisterRequest {
username: string;
age: number;
agreeProtocol: boolean;
}
// 函数参数用接口类型校验，返回值也可以加类型（可选）
async function register(data: RegisterRequest) {
// 编辑器会自动提示data需要的字段，传错类型会直接标红
return axios.post('/api/register', data);
}
`
这时候如果你调用register时，传了{ username: "张三", age: "20", agreeProtocol: true }——年龄传了字符串，编辑器会立刻标红提示“age类型不对，需要number”，根本不用等请求发出去就知道错了。
再提个进阶用法：可选参数和返回值类型
实际项目里，接口参数不一定都是必填的，比如修改用户信息的接口，可能只需要传要改的字段，不用传用户名。这时候可以用?标记可选参数：
`typescript
// 修改用户信息的接口，username和age都是可选的
interface UpdateUserRequest {
username?: string;
age?: number;
}
`
另外，接口返回的内容也可以定义类型，比如注册成功后后端返回用户ID，就可以再定义一个RegisterResponse接口，这样拿到返回值时，编辑器会提示你有哪些属性，不会出现“点了不存在的属性”的错误。
最后总结一下，TS做接口请求类型的核心，就是用简单的interface或type，给请求的参数、返回值定好“格式规则”，写代码时提前拦截类型错误，让接口请求更稳，多人协作也少踩坑，就像给外卖写清楚要求，不会拿到不合心意的餐。