告别纯静态：TS 5.5 结合 Zod 实现“零成本”运行时类型安全
那年我在重构一个日活 50 万的用户增长中台时，遇到了一个典型问题：后端 Java 服务返回的 JSON 结构经常因为字段废弃或新增而悄悄改变，TS 的编译时类型检查在运行时完全失效。当时接口返回了一个 user_level 字段，后端把它从 number 改成了 string，本地编译没有任何报错，直到用户点击提现按钮时前端直接白屏。
TS 5.5 的静态类型系统再强，也管不到网络请求回来的那串字符。我现在的方案是：用 Zod 做运行时校验，同时利用 TS 5.5 的类型推断直接复用 Zod 的定义，避免维护两份类型。
先看一个真实的接口响应处理代码：
// TS 5.5 + Zod 3.23
import { z } from 'zod';
// 定义后端返回的用户资产结构
const UserAssetSchema = z.object({
user_id: z.string().uuid(),
balance: z.number().min(0),
// 后端可能返回 null，也可能返回 undefined，我直接在这里兜底
last_login: z.string().datetime().nullable().optional(),
// 这里用了 TS 5.5 增强的 infer 能力，自动推导联合类型
vip_level: z.union([z.literal(1), z.literal(2), z.literal(3)]),
});
// 关键：直接从 Schema 推导 TS 类型，不需要手写 interface
type UserAsset = z.infer<typeof UserAssetSchema>;
// 封装一个带运行时校验的 fetch
async function fetchUserAsset(userId: string): Promise<UserAsset> {
const res = await fetch(`https://api.xxx.com/v2/asset?uid=${userId}`);
const raw = await res.json();
// 运行时校验，失败直接抛错，不会污染后续业务逻辑
const result = UserAssetSchema.safeParse(raw);
if (!result.success) {
// 真实场景下我会把错误上报到 Sentry
console.error('资产接口类型异常', result.error.format());
throw new Error('数据校验失败');
}
return result.data;
}
// 使用
const asset = await fetchUserAsset('a1b2c3');
// asset.vip_level 在这里已经是 1 | 2 | 3，编辑器提示完全准确
if (asset.vip_level === 3) {
console.log('给黑金用户展示专属入口');
}
我为什么不用 interface 再配合 as 断言？去年 11 月的一次线上事故就是这么来的：后端把 balance 字段从分改成了元，前端没做校验直接 asset.balance / 100，导致用户提现金额被放大 100 倍。如果当时用了 Zod，在校验阶段就会因为 balance 是小数而直接报错。
TS 5.5 的 infer 增强在这里帮了大忙。以前写复杂联合类型推导时，我经常需要手动写一堆条件类型，现在 Zod 配合 TS 5.5 的语言服务，编辑器能直接把 z.infer 的结果精确到字面量级别。
再补一个真实场景：我们那个中台有 30 多个接口，以前每次后端改字段，我要同时改 .d.ts 文件和运行时逻辑。现在只改 Zod Schema，类型定义和校验逻辑一次性搞定。QPS 峰值 8000 时，Zod 的校验开销在 0.3ms 以内，对性能几乎没影响，这才是真正的“零成本”。
---
百万DAU电商订单系统：复杂状态类型推导与性能压测实录
今年 3 月我们上线了一个新订单中心，服务百万 DAU 的电商小程序。订单状态极其复杂：待付款、已付款、备货中、已发货、已签收、退款中、退款完成，再加上各种异常分支，光状态就有 12 个。我一开始用 enum 加 interface 硬写，结果类型推导直接把 TS 编译速度拖慢了 40%。
后来我换成了 TS 5.5 的 联合类型 + 类型守卫 方案，配合状态机的思路，编译时间从 800ms 降到了 120ms。先看核心状态定义：
// TS 5.5 联合类型 + 判别式
type OrderStatus =
| { tag: 'pending_payment'; expire_at: number }
| { tag: 'paid'; paid_at: number; logistics_id?: string }
| { tag: 'shipped'; tracking_no: string; shipped_at: number }
| { tag: 'refunding'; refund_id: string; apply_at: number };
// 订单主类型
type Order = {
order_id: string;
user_id: string;
status: OrderStatus;
items: Array<{
sku_id: string;
price: number;
qty: number;
}>;
};
// 类型守卫，TS 5.5 会自动收窄类型
function isShipped(order: Order): order is Order & { status: { tag: 'shipped' } } {
return order.status.tag === 'shipped';
}
// 真实业务逻辑：只有已发货订单才能展示物流
function renderLogistics(order: Order) {
if (isShipped(order)) {
// 这里 status 已经被收窄，可以直接访问 tracking_no
return `物流单号：${order.status.tracking_no}`;
}
return '暂未发货';
}
// 模拟大促时的订单列表处理
const orders: Order[] = [
{
order_id: 'O001',
user_id: 'U001',
status: { tag: 'shipped', tracking_no: 'SF123', shipped_at: Date.now() },
items: [{ sku_id: 'S001', price: 299, qty: 2 }]
},
{
order_id: 'O002',
user_id: 'U002',
status: { tag: 'pending_payment', expire_at: Date.now() + 1800000 },
items: [{ sku_id: 'S002', price: 99, qty: 1 }]
}
];
// 批量处理：找出所有已发货订单
const shippedOrders = orders.filter(isShipped);
console.log(shippedOrders.length); // 1
这个方案在大促压测时的表现：单节点 8C16G 配置，处理 5000 QPS 的订单查询请求，TS 编译后的 JS 代码在 V8 引擎里执行，状态判断的 CPU 占用只有 2.3%。我之前用 enum + switch 的方案，每个状态判断都要做一次属性访问，压测时 CPU 直接飙到 15%。
为什么不用 Redux 那种复杂的状态管理类型？我们的订单状态是后端驱动的，前端只需要做展示和简单的状态流转。用联合类型 + tag 判别式，TS 5.5 的编译器能直接做 穷尽性检查。如果以后新增一个 cancelled 状态，我只要在 OrderStatus 里加一个分支，所有没处理这个状态的 switch 语句都会直接编译报错，不会出现线上漏处理的情况。
压测时我还发现一个细节：TS 5.5 的增量检查（Project References）对大型订单模块特别友好。我们订单模块有 120 多个 TS 文件，改一个状态类型，以前要重新编译整个模块，现在只编译受影响的 3 个文件，本地开发时的热更新延迟从 1.2 秒降到了 200ms 以内。
---
深度复盘：一次因 any 类型泄漏引发的线上P0事故与修复方案
去年双 11 大促前一周，我们的商品详情页突然大面积报错，报错率 3 分钟内冲到 8%，直接触发 P0 告警。我盯着监控看，发现是商品规格选择器组件崩溃了，报错信息是 Cannot read property 'price' of undefined。
排查过程很直接：先看报错堆栈，定位到 sku-selector.tsx 的第 47 行。代码是这样的：
// 事故代码：any 类型泄漏
function getSkuPrice(skuData: any) {
// 后端返回结构变了，但 any 让 TS 完全失声
return skuData.specs[0].price;
}
// 组件里直接调用
const price = getSkuPrice(product.sku_list);
问题根源是后端把 specs 字段从数组改成了对象，但 skuData 被定义成了 any，TS 编译时没有任何提示。我当时的修复方案分三步：
第一步：立刻止血
在 getSkuPrice 里加兜底逻辑，先上线救急：
// 紧急修复：加运行时兜底
function getSkuPrice(skuData: any) {
// 先判断 specs 是不是数组
if (!Array.isArray(skuData?.specs) || skuData.specs.length === 0) {
return 0; // 兜底价格
}
return skuData.specs[0].price || 0;
}
第二步：彻底消除 any
用 TS 5.5 的类型推导重写整个 SKU 模块。我先把后端的返回结构用 type 精确描述出来：
// 精确类型定义
type SkuSpec = {
spec_id: string;
spec_name: string;
price: number;
stock: number;
};
type SkuData = {
sku_id: string;
specs: SkuSpec[]; // 明确是数组，不是 any
images: string[];
};
// 重写函数，参数类型严格约束
function getSkuPrice(skuData: SkuData): number {
// 现在 TS 会直接报错如果 specs 不是数组
const firstSpec = skuData.specs[0];
// 用可选链 + 空值合并，双重保险
return firstSpec?.price ?? 0;
}
// 模拟后端数据
const mockSkuData: SkuData = {
sku_id: 'SKU001',
specs: [{ spec_id: 'S1', spec_name: '红色', price: 199, stock: 50 }],
images: ['https://xxx.com/1.jpg']
};
console.log(getSkuPrice(mockSkuData)); // 199
第三步：全局 any 扫描
我写了一个简单的脚本，扫描整个项目里的 any 类型使用：
# 用 ts-prune 配合 grep 找 any
npx tsc --noEmit | grep "implicitly has an 'any' type"
结果吓一跳：整个项目有 127 处 any 泄漏，大部分都在接口返回处理的地方。我花了两天时间，把核心交易链路的 43 处 any 全部替换成了精确类型，同时开启了 tsconfig.json 里的两个配置：
{
"compilerOptions": {
"strict": true,
"noImplicitAny": true,
"strictNullChecks": true
}
}
开启后，编译时直接报出了 21 个潜在的空指针问题，全部修复后，那次大促期间商品详情页的报错率降到了 0.01% 以下。
这次事故让我定了个规矩：除了第三方无类型声明的 JS 库（用 // @ts-ignore 临时处理并加 TODO），业务代码里严禁出现 any。TS 5.5 的类型推断已经足够强，哪怕后端返回结构复杂，用 z.infer 或者联合类型也能精确描述，没必要用 any 偷懒。偷懒的代价就是半夜被告警叫起来修 P0，这比写类型定义累多了。
4. 装饰器落地实战：从 Stage 3 提案看 NestJS 依赖注入的演进
去年我们团队重构一个运行了三年的老 NestJS 服务，当时还在用 TS 4.8，装饰器还是那个实验性的 experimentalDecorators。我记得特别清楚，那个订单服务的 OrderService 里塞了十几个 @Inject()，因为当时 Nest 的依赖注入容器对自定义 Provider 的识别全靠这些装饰器元数据。后来升级到 TypeScript 5.5，我第一件事就是把 tsconfig 里的 experimentalDecorators 关了，改成 "target": "ES2022" 配合新的 Stage 3 装饰器提案支持，整个项目的编译速度直接从 800ms 降到了 120ms 左右，尤其是在冷启动的时候，增量编译的体验提升太明显了。
为什么我要折腾这个？因为老的装饰器实现其实是 TS 团队自己搞的一套临时方案，跟现在的 ECMAScript 标准完全脱节。你写个 @Injectable()，底层其实是靠 Reflect.metadata 在运行时挂数据，一旦你忘了加 reflect-metadata 这个 polyfill，或者打包时 tree-shaking 把它抖掉了，服务启动直接报 Reflect.metadata is not a function，我们去年大促前就因为这个线上翻车过一次，排查了整整两个小时。
新的 Stage 3 装饰器不一样，它是直接作为语言层面的函数存在。我拿我们现在的用户认证模块举个例子，以前定义一个 Guard 得这么写：
// 老写法，依赖 experimentalDecorators
import { Injectable, CanActivate, ExecutionContext } from '@nestjs/common';
import { Reflect } from 'reflect-metadata';
@Injectable()
export class AuthGuard implements CanActivate {
canActivate(context: ExecutionContext): boolean {
const request = context.switchToHttp().getRequest();
return this.validateToken(request.headers.authorization);
}
private validateToken(token: string): boolean {
// 实际验证逻辑
return !!token;
}
}
// 控制器里用的时候
@Controller('orders')
export class OrderController {
@UseGuards(AuthGuard)
@Get(':id')
getOrder(@Param('id') id: string) {
return { id };
}
}
现在用 TS 5.5 的新装饰器，我可以把元数据直接挂在装饰器函数本身，不需要再依赖外部的 Reflect API。我们现在的权限装饰器是这么实现的：
// TS 5.5 新装饰器写法，不需要 experimentalDecorators
type Permission = 'read:order' | 'write:order';
function RequirePermission(permission: Permission) {
// 装饰器直接返回一个函数，接收目标类的原型、属性名、属性描述符
return function <T extends (...args: any[]) => any>(
target: Object,
propertyKey: string | symbol,
descriptor: TypedPropertyDescriptor<T>
) {
const originalMethod = descriptor.value!;
// 把权限信息直接挂到方法上，不需要 Reflect.metadata
(originalMethod as any).requiredPermission = permission;
descriptor.value = function (...args: any[]) {
const user = args[0]?.user; // 假设第一个参数是请求上下文
if (user?.permissions?.includes(permission)) {
return originalMethod.apply(this, args);
}
throw new Error('Permission denied');
} as T;
return descriptor;
};
}
class OrderController {
// 直接调用装饰器，类型检查会在编译时直接报错，而不是运行时才发现问题
@RequirePermission('read:order')
getOrder(id: string, ctx: { user: { permissions: string[] } }) {
return { id, user: ctx.user };
}
}
// 测试一下
const controller = new OrderController();
try {
controller.getOrder('123', { user: { permissions: [] } });
} catch (e) {
console.log(e.message); // 直接输出 Permission denied，不需要任何 polyfill
}
这里有个细节，TS 5.5 对装饰器的参数类型推断比之前准多了。以前你写装饰器，如果参数类型没标对，编译器只会给你个模糊的 any 警告，现在它会直接告诉你“装饰器第二个参数应该是 string | symbol”，我们团队有个新来的同学之前把 propertyKey 写成 number，以前要跑起来才知道错，现在写的时候就直接红了。
还有个实际的问题，我们之前有个微服务用老的装饰器写了一堆自定义 Provider，升级的时候发现 NestJS 5.0 之后其实已经悄悄支持了部分新装饰器特性，但文档没写全。我当时排查的时候发现，新的装饰器在编译后不会生成多余的 _decorate 辅助函数，我们那个服务的打包体积直接小了 17KB（gzip 后），对于 QPS 常年 3000+ 的支付回调服务来说，这点体积优化其实对冷启动时间影响挺明显的。
现在 ECMAScript 装饰器提案已经到 Stage 3 了，TS 5.5 这次跟进之后，我估计明年 NestJS 8 肯定会全面切到新标准。如果你现在还在用老装饰器，我建议先把 strict 模式开全，尤其是 strictFunctionTypes，不然升级的时候类型错误能让你改到怀疑人生。我们当时改了大概 30 多个文件，大部分都是因为以前装饰器参数类型太宽松导致的，改完之后运行时错误直接少了 40% 左右。
5. 类型体操的边界：在 React 组件库中实现类型安全与可维护性平衡
去年我们给公司做内部组件库，有个 Table 组件要支持动态列配置，当时团队里有个喜欢玩类型体操的同学，把列的类型定义写了一百多行，用了三层条件类型加映射类型，最后实现了“列配置的类型完全根据数据源类型自动推导”。听起来很酷对吧？结果上线后第三周，有个业务方想加个自定义渲染列，传了个函数进去，类型报错报得他一脸懵，跑过来问我怎么回事。我看了眼那个类型定义，连我自己都看不懂了——这就是典型的类型体操过度。
我后来把那个类型定义拆成了三个部分，核心原则就是：类型复杂度不能超过组件的使用场景复杂度。我们那个 Table 组件最常用的场景是“数据源是固定接口返回的对象数组”，比如订单列表的接口返回长这样：
// 订单接口返回类型，实际项目里是从后端 swagger 生成的
interface OrderItem {
id: string;
orderNo: string;
amount: number;
status: 'pending' | 'paid' | 'shipped';
createdAt: string;
}
以前那个过度设计的类型是这么写的（我简化了一下，实际更长）：
// 过度设计的类型，别学这个
type ColumnConfig<T, K extends keyof T = keyof T> = K extends any
? {
key: K;
title: string;
render?: (value: T[K], record: T, index: number) => React.ReactNode;
}
: never;
type TableProps<T> = {
dataSource: T[];
columns: ColumnConfig<T>[];
};
这个类型的问题在哪？当你传 columns 的时候，如果少写了一个 key，或者 render 函数的参数类型写错，编译器给你的错误提示是一串嵌套的条件类型展开，业务方根本看不懂。而且我们后来发现，90% 的场景下 columns 都是固定的，只有 10% 的场景需要自定义 render，完全没必要把类型搞得这么复杂。
我后来改成了这样，用泛型约束加明确的类型别名，把复杂度控制在刚好够用的程度：
// 实用主义的类型设计
import React from 'react';
// 先定义列的基础类型，明确每个字段的用途
type BaseColumn<T> = {
key: keyof T;
title: string;
// render 函数的参数类型直接写死，不用条件类型推导
render?: (value: T[keyof T], record: T, index: number) => React.ReactNode;
};
// Table 组件的 props 类型，泛型 T 就是数据源的类型
type TableProps<T extends Record<string, any>> = {
dataSource: T[];
columns: BaseColumn<T>[];
// 加个可选的 loading 状态，类型直接写 boolean
loading?: boolean;
};
// 组件实现，用 React.FC 配合泛型
const Table = <T extends Record<string, any>>(props: TableProps<T>) => {
const { dataSource, columns, loading } = props;
if (loading) return <div>加载中...</div>;
return (
<table>
<thead>
<tr>
{columns.map(col => (
<th key={String(col.key)}>{col.title}</th>
))}
</tr>
</thead>
<tbody>
{dataSource.map((record, index) => (
<tr key={record.id || index}>
{columns.map(col => (
<td key={String(col.key)}>
{col.render
? col.render(record[col.key], record, index)
: record[col.key]}
</td>
))}
</tr>
))}
</tbody>
</table>
);
};
// 实际使用，类型提示非常清晰
const orderColumns: BaseColumn<OrderItem>[] = [
{ key: 'orderNo', title: '订单号' },
{ key: 'amount', title: '金额', render: (val) => `¥${val}` }, // 这里 val 的类型自动推导为 number
{ key: 'status', title: '状态' },
];
const OrderTable = () => {
const [loading, setLoading] = React.useState(false);
const [data, setData] = React.useState<OrderItem[]>([]);
React.useEffect(() => {
setLoading(true);
// 模拟接口请求，实际项目里用 axios 或者 swr
setTimeout(() => {
setData([
{ id: '1', orderNo: 'O123', amount: 100, status: 'paid', createdAt: '2024-06-01' },
]);
setLoading(false);
}, 500);
}, []);
return <Table dataSource={data} columns={orderColumns} loading={loading} />;
};
改完之后，业务方再写自定义列的时候，如果 render 函数的参数类型写错，比如把 value 当成字符串处理，编译器会直接提示“number 类型不能赋值给 string”，而不是一堆看不懂的条件类型错误。我们后来统计了一下，组件库的类型相关 issue 从每月 7-8 个降到了 1-2 个，维护成本直接降了 70%。
这里有个我踩过的坑：之前为了“完美”支持动态列，我给 columns 加了个 hidden 字段，类型是 boolean | ((record: T) => boolean)，然后想用类型体操让 hidden 为 true 的时候 render 可选。结果写出来之后，业务方传 hidden: (record) => record.status === 'pending' 的时候，类型推导直接失效，因为条件类型没法处理这种运行时才能确定的函数返回值。后来我干脆把这个逻辑放到组件内部实现，类型里只保留 hidden?: boolean，需要动态隐藏的列就让业务方自己过滤 dataSource，反而更清晰。
类型体操不是不能用，比如你要写个 DeepReadonly 或者 PickByType 这种通用工具类型，用条件类型和映射类型完全没问题。但到了业务组件层面，类型的作用是“帮使用者少犯错”，而不是“炫技”。我们团队现在有个约定：单个类型定义不能超过 20 行，嵌套层级不能超过 3 层，超过的话必须拆成多个基础类型。这个约定执行之后，新同学接手组件库的类型定义，平均上手时间从 3 天降到了 1 天。
6. 全栈提效：Next.js 中前后端共享类型定义的工程化实践
今年年初我们用 Next.js 14 做了个电商后台系统，当时最头疼的就是前后端类型不同步的问题。后端用 NestJS 写的接口，返回的用户信息类型改了个字段，前端不知道，调接口的时候直接用旧类型，结果页面白屏。后来我们搞了个类型共享的方案，现在后端改了接口类型，前端 10 秒内就能收到类型错误提示，不用等联调才发现。
我们的方案其实很简单：把后端接口返回的类型定义单独抽成一个 npm 包，前后端都依赖这个包。但实际操作的时候有几个细节要注意，尤其是 Next.js 的目录结构和 TS 5.5 的模块解析规则。
首先，我们在项目根目录下建了个 types 文件夹，专门放共享类型，然后用 tsconfig.json 的 paths 配置让前后端都能引用到。不过后来发现 Next.js 的 next.config.js 默认不会处理 paths，所以得配合 @next/bundle-analyzer 和 tsconfig-paths-webpack-plugin 来配置，不然打包的时候会找不到类型文件。
我拿用户模块举个例子，后端的用户接口返回类型是这么定义的，放在 types/src/user.ts 里：
// types/src/user.ts
// 后端用 class 定义，方便用 class-validator 做参数校验
import { IsString, IsEmail, MinLength } from 'class-validator';
export class UserDTO {
@IsString()
id: string;
@IsEmail()
email: string;
@IsString()
@MinLength(2)
name: string;
// 后端返回的时候不会带密码字段，所以这里不用定义
// 但前端需要个类型，所以我们单独导出前端的类型
}
// 前端用的用户类型，去掉后端校验相关的装饰器，只保留字段
export type FrontendUser = Omit<UserDTO, never>; // 这里其实直接复制字段更简单，我们实际是这么写的：
export type FrontendUser = {
id: string;
email: string;
name: string;
};
// 接口响应的通用类型，前后端都用这个
export type ApiResponse<T> = {
code: number;
data: T;
message: string;
};
然后我们在 types/package.json 里配置这个包的名字是 @internal/shared-types，然后用 tsup 打包成 CommonJS 和 ESModule 两种格式，这样前后端都能引用。不过后来发现 Next.js 13+ 支持直接引用 .ts 文件，所以我们其实不用打包，直接在 tsconfig.json 里配 paths 就行：
// tsconfig.json（根目录）
{
"compilerOptions": {
"target": "ES2022",
"module": "ESNext",
"moduleResolution": "Bundler",
"paths": {
"@shared/*": ["./types/src/*"]
}
}
}
接下来是后端怎么用这个类型。我们的 NestJS 接口控制器里直接引用 @shared/user，返回类型标上 ApiResponse，这样如果后端返回的数据少了字段，TS 会直接报错：
// apps/backend/src/user/user.controller.ts
import { Controller, Get, Param } from '@nestjs/common';
import { ApiResponse, FrontendUser } from '@shared/user';
import { UserService } from './user.service';
@Controller('users')
export class UserController {
constructor(private readonly userService: UserService) {}
@Get(':id')
async getUser(@Param('id') id: string): Promise<ApiResponse<FrontendUser>> {
const user = await this.userService.findById(id);
// 如果 user 少了 email 字段，这里 TS 会直接报错
return {
code: 200,
data: {
id: user.id,
email: user.email,
name: user.name,
},
message: 'success',
};
}
}
前端这边，我们在 Next.js 的 app/api/users/[id]/route.ts 里调用后端接口，或者直接在 React 组件里用 fetch 请求，类型直接从 @shared/user 拿，不用自己再定义一遍：
// apps/frontend/app/users/[id]/page.tsx
import { ApiResponse, FrontendUser } from '@shared/user';
import { notFound } from 'next/navigation';
// Next.js 服务端组件里直接请求后端接口
const getUser = async (id: string): Promise<FrontendUser> => {
const res = await fetch(`http://backend:3000/users/${id}`, {
cache: 'no-store',
});
const json: ApiResponse<FrontendUser> = await res.json();
if (json.code !== 200) notFound();
return json.data;
};
export default async function UserPage({ params }: { params: { id: string } }) {
const user = await getUser(params.id);
return (
<div>
<h1>{user.name}</h1>
<p>邮箱：{user.email}</p>
</div>
);
}
这里有个实际遇到的问题：我们后端有一次把 UserDTO 里的 name 字段改成了 username，结果前端的 FrontendUser 类型没同步，编译的时候没报错，因为 FrontendUser 是我们手动复制的。后来我干脆写个脚本，每次后端类型改了之后，自动把 UserDTO 的字段同步到 FrontendUser，用 ts-morph 来解析 AST，自动生成前端的类型定义，现在只要后端一改类型，跑一下脚本，前端的类型就自动更新了。
还有个细节，Next.js 的 fetch 在 TS 5.5 里有个小问题，如果你直接把 await res.json() 赋值给 ApiResponse 类型，TS 不会报错，因为 res.json() 返回的是 any。我们后来封装了个 request 函数，用泛型约束返回类型：
// apps/frontend/lib/request.ts
import { ApiResponse } from '@shared/user';
async function request<T>(url: string): Promise<T> {
const res = await fetch(url);
const json: ApiResponse<T> = await res.json();
if (json.code !== 200) throw new Error(json.message);
return json.data;
}
// 使用的时候
const user = await request<FrontendUser>(`/api/users/${id}`);
现在我们的流程是：后端改接口类型 → 跑类型同步脚本 → 前端 tsc --noEmit 检查 → 如果有类型错误直接修复。上次后端把订单接口的 amount 从 number 改成 string（因为要支持精度更高的金额），前端的类型检查直接报了 12 个错误，我们半小时就全改完了，不用等到联调的时候才发现页面显示 NaN。
这个方案我们跑了半年，前后端类型不一致导致的问题从每月 5-6 次降到了 0 次。唯一要注意的是，共享类型包不要放太多业务逻辑相关的类型，只放接口输入输出类型，不然前端会依赖太多后端的东西，打包体积可能会变大。我们现在的共享类型包体积只有 12KB，对前端性能几乎没影响。
站长实战手记
一次让我改掉“any 走天下”习惯的重构
去年我接手了一个做了三年的内部 CRM 系统，代码量大概 8 万行。接手的时候我很头大，前任开发为了赶进度，几乎全用的 any。我印象最深的是订单模块，一个订单对象在不同接口里字段居然不一样，有的有 discount，有的没有，全靠前端硬写判断。
有一次线上出问题，后端把 price 从 number 改成了 string，前端没报错，直到用户下单时才发现计算全乱了。我当时排查了整整一个下午，最后发现是类型系统完全失效了。
后来我带着两个同事花了两个月重构。我们没搞那种特别复杂的类型体操，而是做了几件事：
* 用 Zod 接管了所有接口返回值的校验，入库前先过一遍 schema
* 把核心的订单、用户、权限三个模块的类型全部收敛到 shared/types 里
* 强制关掉了 tsconfig 里的 implicitAny，宁可多写几行也不让 any 偷偷混进来
重构完之后，那个月因为类型不匹配导致的线上 bug 直接降到了零。不过我也得说实话，不是所有地方都值得这么干。比如一些生命周期很短的运营活动页，我依然会写得很“糙”，因为投入产出比不划算。
我现在越来越觉得，TypeScript 不是越复杂越好。如果你发现为了写一个类型，得嵌套七八层条件判断，那大概率是你把简单问题搞复杂了。
给正在学类型的朋友一个建议：别急着去刷什么“类型体操”面试题。先去把你手头项目里最痛的那个 any 改掉，那种“终于不报错了”的爽感，比背一百个高级语法都有用。