类型驱动开发（Type-Driven Development）：让类型约束先行为导向

1. 技术难点：为什么类型会被"当摆设"

很多项目虽然用了 TypeScript，但实际是"给已有的 JS 加标注 "------先写逻辑，再补类型，甚至用 any 糊过去。这样类型系统形同虚设：

any 泛滥 ：一遇到复杂逻辑就 as any 跳过，类型检查失去意义。
类型和实现脱节：先写代码再补类型，类型经常是"事后描述"，无法约束行为。
改需求崩一片：数据模型变了，调用方不知道，运行时才炸。
接口耦合：前后端/跨模块传值，类型没统一，靠文档和猜。

核心难点 ：如何让类型先行------先用类型精确刻画"数据的形状和约束"，再据此实现，从而：

编译期就拦下大多数错误（少写、错字段、不该传的都过不了）
类型成为团队的"可执行文档"和契约
改模型时，编译器告诉你所有要改的地方（而不是漏改）

2. 完整解法：类型驱动开发的五步法

2.1 先定义"领域类型"（类型即契约）

动手写逻辑前，先精确刻画数据模型。不是草率 interface，而是把可选、只读、字面量、联合都用上：

ts 复制代码

// 用字面量类型 + 联合约束取值范围，杜绝魔法字符串
type OrderStatus = 'pending' | 'paid' | 'shipped' | 'cancelled';
type Currency = 'CNY' | 'USD';

// 用 readonly 表达不可变
interface Order {
  readonly id: string;        // 只读，防误改
  amount: number;
  currency: Currency;
  status: OrderStatus;
  items: readonly OrderItem[];  // 数组只读
}

// 用可选 + 明确空态，别用 any/undefined 模糊
interface User {
  id: number;
  name: string;
  email?: string;          // 可空但明确
  phone: string | null;    // null 有语义（未填）vs 缺失
}

关键：类型要能表达"什么不可能发生"，这样编译器帮你排除。

2.2 让非法状态"不可表示"（Make Illegal States Unrepresentable）

这是类型驱动开发的精髓------设计类型时，让"错误的组合"根本表达不出来：

ts 复制代码

// ❌ 反例：status 和 paidAt 可能不一致（pending 也能有 paidAt）
interface BadOrder { status: string; paidAt?: Date; }

// ✅ 用联合类型 + 不同结构，让非法组合类型上报错
type Order =
  | { status: 'pending' }
  | { status: 'paid'; paidAt: Date; paymentId: string }
  | { status: 'shipped'; trackingNo: string };

// 使用时可直接判别（type narrowing），编译器保证分支正确
function describe(o: Order) {
  if (o.status === 'paid') {
    return `已支付 ${o.paymentId}`;   // 这里有 paymentId，编译器保证
  }
  // o.status === 'pending' 时不可能访问 o.paymentId
}

这样"未支付却有支付记录"这类 bug，在类型层面就不存在。

2.3 先写函数签名，再实现（Signature First）

实现前先把函数类型签名写清楚，头尾都用强类型：

ts 复制代码

// 先定契约：输入、输出、可能抛错
type Result<T> = { ok: true; value: T } | { ok: false; error: string };

// 实现被签名约束，直接照着写
function processOrder(orderId: string): Promise<Result<Order>> {
  // 实现时你很清楚：成功返回 {ok:true,value}，失败返回 {ok:false,error}
  const order = fetchOrder(orderId);
  if (!order) return { ok: false, error: '订单不存在' };
  return { ok: true, value: order };
}

Result 模式 ：用"成功/失败联合"显式表达错误，替代裸的 throw/null，调用方能穷举处理。

2.4 用工具类型驱动"派生"

从基础模型派生不用手写一堆重复类型：

ts 复制代码

interface User { id: number; name: string; email: string; password: string; }

// 面向用户视图：剔除敏感字段
type PublicUser = Omit<User, 'password'>;
// 创建参数：密码必填，其余可选
type CreateUserDto = Pick<User, 'name' | 'email'> & { password: string };
// 更新参数：全部可选
type UpdateUserDto = Partial<Omit<User, 'id'>>;

2.5 结合运行时校验（类型 + 校验双保险）

类型只存在于编译期（TS 编译后就没了），运行时拿到的数据不一定是类型声明的样子。生产环境要配合运行时校验（zod 之类）：

ts 复制代码

import { z } from 'zod';

// 用 zod 定义 schema（运行时校验 + 推导出 TS 类型）
const OrderSchema = z.object({
  id: z.string(),
  amount: z.number().positive(),
  status: z.enum(['pending', 'paid', 'shipped', 'cancelled']),
});
type Order = z.infer<typeof OrderSchema>;   // 从 schema 推导类型

// 运行时：解析外部数据（API 响应/请求体），不合法就抛
const parsed = OrderSchema.parse(apiResponse);  // 类型也是 Order

分工：TS 类型管"编译期约束"，zod/joi 管"运行时校验"，两者用 z.infer 关联，一套 schema 双用，杜绝"类型说有、运行时没有"。

3. 应用场景

场景	类型驱动价值
前后端接口传值	类型统一契约，改模型编译器提醒所有调用方
复杂状态机（订单/审批）	判别联合让非法状态不可表示
表单/请求体校验	zod schema 一套双用（类型+运行时）
组件 API 设计	强类型 props 约束组件用法
大型项目重构	类型当"编译器帮你找出所有受影响的代码"

解决的具体问题：

any 泛滥、类型形同虚设
改变量结构漏改调用方（运行时才炸）
状态组合非法（未支付却有支付记录）
类型和运行时数据不一致

4. 要点总结

类型先行：先刻画"数据形状 + 不可能发生的状态"，再实现。
Make Illegal States Unrepresentable：让非法组合在类型层面表达不出来，是类型驱动核心。
判别联合 + 字面量：替代 string 魔法值，配合 type narrowing 获得安全分支。
Signature First：先写函数签名（含 Result 错误模式）再实现。
工具类型派生：Omit/Pick/Partial 从基础模型派生视图/参数类型。
编译期 + 运行时双保险 ：TS 类型管编译期，zod 管运行时，z.infer 让一套 schema 双用。
别过度设计：小项目/一次性代码不必强上，类型驱动收益在模型复杂、协作多、易变的场景最大。

一句话：类型驱动开发不是"补类型"，而是让类型成为契约和护栏------先定义"什么合法、什么不可能"，编译器就能在写错时、改需求时、传错数据时帮你拦下，而不是等线上炸。