【TS】从基础到进阶，总结业务中的实践运用

TypeScript 的魅力在于把隐性约定变成显性约束——但随着业务复杂度上升，基础的interface和type已经不够用了。比如：

怎么优雅过滤 union 类型中的“内部成员”？
树状数据（导航栏、评论）如何定义类型？
怎么避免路由/类名的拼写错误？

趁热打铁，继上篇，今天分享 5 个我在项目中高频使用的 TypeScript 进阶技巧，每个都结合真实场景，帮你把 TS 从“能用”升级到“好用”～

一、分布式条件类型：union 类型的“过滤神器”#

你有没有遇到过“从 union 类型中删掉某类成员”的需求？比如从string | number | boolean中排除string——这时候分布式条件类型（DCT）就是你的救星！

1. 基础逻辑：拆 union、逐个判#

DCT 的核心是：对 union 类型的每个成员单独应用条件判断，像“拆快递”一样逐个检查。

比如我们想写一个ExcludeString类型，把string从 union 中删掉：

1
// 逻辑：如果T是string，就返回never（丢弃），否则返回T本身
2
type ExcludeString<T> = T extends string ? never : T
3

4
type Mixed = string | number | boolean
5
type NoString = ExcludeString<Mixed> // number | boolean（正确过滤掉string）

TS 内置了两个常用的 DCT 工具类型，帮你省去自定义的麻烦：

Exclude<T, U>：从 T 中排除所有能赋值给 U 的类型；
Extract<T, U>：从 T 中提取所有能赋值给 U 的类型。

比如从数字 union 中提取偶数：

1
type Numbers = 1 | 2 | 3 | 4
2
type Even = Extract<Numbers, 2 | 4> // 2 | 4（提取偶数）
3
type Odd = Exclude<Numbers, Even> // 1 | 3（排除偶数）

2. 真实场景：过滤 Redux 的内部 Action#

在 Redux 中，我们常定义“内部 Action”（比如日志、监控），这些 Action 不应该暴露给组件。用 DCT 可以轻松过滤：

1
// 所有Action类型：包含用户操作和内部操作
2
type Action =
3
  | { type: 'user/login'; payload: { token: string } } // 用户登录
4
  | { type: 'user/logout' } // 用户登出
5
  | { type: 'internal/logger'; payload: { message: string } } // 内部日志
6
  | { type: 'internal/monitor'; payload: { metric: string } } // 内部监控
7

8
// 提取所有内部Action（type以internal/开头）
9
type InternalAction = Extract<Action, { type: `internal/${string}` }>
10

11
// 过滤内部Action，得到公共Action类型
12
type PublicAction = Exclude<Action, InternalAction>
13

14
// 组件只能dispatch公共Action，避免误操作！
15
const dispatchPublic = (action: PublicAction) => dispatch(action)
16

17
dispatchPublic({ type: 'user/login', payload: { token: 'xxx' } }) // ✅ 允许
18
dispatchPublic({ type: 'internal/logger', payload: { message: 'test' } }) // ❌ 编译报错！

二、递归类型：树状数据的“完美描述符”#

树状数据（导航栏、评论、JSON Schema）的核心是嵌套递归——TypeScript 的递归类型能完美描述这种结构，避免重复定义。

1. 基础用法：定义复杂导航树#

实际项目中的导航栏，往往包含icon（图标）、permissions（权限）、children（子菜单）等属性：

1
// 导航节点类型：支持图标、权限、展开状态
2
type NavNode = {
3
  id: string // 唯一标识
4
  name: string // 显示名称
5
  icon?: string // 图标（比如"home"）
6
  permissions?: string[] // 访问权限（比如["admin", "editor"]）
7
  isExpanded?: boolean // 是否展开子菜单
8
  children?: NavNode[] // 子节点（递归引用自己）
9
}
10

11
// 示例导航树：首页+产品中心+设置
12
const navTree: NavNode[] = [
13
  { id: 'home', name: '首页', icon: 'home', permissions: ['user', 'admin'] },
14
  {
15
    id: 'products',
16
    name: '产品中心',
17
    icon: 'box',
18
    permissions: ['admin'],
19
    children: [
20
      { id: 'products-list', name: '产品列表' },
21
      { id: 'products-add', name: '添加产品', permissions: ['admin'] },
22
    ],
23
  },
24
  {
25
    id: 'settings',
26
    name: '设置',
27
    icon: 'gear',
28
    children: [
29
      { id: 'settings-user', name: '用户设置' },
30
      { id: 'settings-system', name: '系统设置', permissions: ['admin'] },
31
    ],
32
  },
33
]

2. 真实场景：评论线程与 JSON Schema#

评论系统的“回复嵌套”是典型的递归场景——用递归类型定义Comment，支持无限层级的回复：

1
// 评论类型：支持回复、点赞、作者信息
2
type Comment = {
3
  id: string // 评论ID
4
  content: string // 评论内容
5
  author: { id: string; name: string } // 作者
6
  likes: number // 点赞数
7
  createdAt: string // 创建时间
8
  replies?: Comment[] // 回复列表（递归）
9
}
10

11
// 示例评论：包含两条回复
12
const comments: Comment[] = [
13
  {
14
    id: 'c1',
15
    content: '这篇文章写得真好！',
16
    author: { id: 'u1', name: 'Alice' },
17
    likes: 10,
18
    createdAt: '2024-01-01',
19
    replies: [
20
      {
21
        id: 'c2',
22
        content: '同意！学到了很多。',
23
        author: { id: 'u2', name: 'Bob' },
24
        likes: 5,
25
        createdAt: '2024-01-02',
26
      },
27
      {
28
        id: 'c3',
29
        content: '请问递归类型怎么处理无限嵌套？',
30
        author: { id: 'u3', name: 'Charlie' },
31
        likes: 3,
32
        createdAt: '2024-01-03',
33
      },
34
    ],
35
  },
36
]

三、索引访问类型：嵌套结构的“精准钥匙”#

想取对象深层嵌套字段的类型？比如Product['details']['manufacturer']['country']——索引访问类型就是打开嵌套结构的“钥匙”。

1. 基础用法：取深层字段类型#

以电商产品为例，我们需要取厂商所在国家的类型：

1
// 电商产品类型：包含多层嵌套
2
type Product = {
3
  id: string
4
  name: string
5
  details: {
6
    price: number // 价格
7
    stock: number // 库存
8
    manufacturer: {
9
      name: string // 厂商名称
10
      country: string // 厂商所在国家（目标字段）
11
    }
12
  }
13
}
14

15
// 用索引访问类型取厂商所在国家的类型
16
type ManufacturerCountry = Product['details']['manufacturer']['country'] // string

2. 进阶：通用深层字段工具#

如果嵌套层级更深，可以写一个递归的深层字段工具，支持任意层数的嵌套：

1
// 递归取深层字段：Path是路径数组（比如['details', 'manufacturer', 'country']）
2
type DeepField<T, Path extends string[]> = Path extends [
3
  infer First,
4
  ...infer Rest
5
]
6
  ? First extends keyof T
7
    ? Rest extends string[]
8
      ? DeepField<T[First], Rest>
9
      : never
10
    : never
11
  : T
12

13
// 用法：取Product→details→manufacturer→country的类型
14
type Country = DeepField<Product, ['details', 'manufacturer', 'country']> // string

3. 真实场景：电商 SKU 筛选#

电商详情页的 SKU 筛选，需要保证筛选条件与 SKU 的实际属性一致：

1
// 产品的SKU类型（来自Product['skus'][number]）
2
type Sku = {
3
  id: string
4
  size: 'S' | 'M' | 'L' | 'XL' // 尺寸
5
  color: 'red' | 'blue' | 'green' // 颜色
6
  quantity: number // 库存
7
}
8

9
// 筛选条件类型：size和color来自SKU的类型
10
type FilterParams = {
11
  size?: Sku['size'] // 只能选S/M/L/XL
12
  color?: Sku['color'] // 只能选red/blue/green
13
}
14

15
// 筛选SKU的函数：确保条件合法
16
function filterSkus(skus: Sku[], params: FilterParams): Sku[] {
17
  return skus.filter(
18
    (sku) =>
19
      (params.size ? sku.size === params.size : true) &&
20
      (params.color ? sku.color === params.color : true)
21
  )
22
}
23

24
// 正确示例：筛选尺寸M、颜色red的SKU
25
filterSkus(skus, { size: 'M', color: 'red' }) // ✅
26

27
// 错误示例：尺寸传XXL（SKU中没有）
28
filterSkus(skus, { size: 'XXL', color: 'red' }) // ❌ 编译报错！

四、带智能回退的条件类型：API 输入的“格式统一器”#

API 设计中常遇到“支持单个值或数组”的需求（比如id可以是 1 或[1,2]）——带智能回退的条件类型能自动统一格式。

1. 基础逻辑：智能判断数组类型#

定义MaybeArray类型：如果输入是数组，返回数组元素类型；否则返回原类型：

1
// 支持readonly数组的MaybeArray
2
type MaybeArray<T> = T extends readonly any[] ? T[number] : T
3

4
// 测试：
5
type ReadonlyArr = readonly string[]
6
type A = MaybeArray<ReadonlyArr> // string（正确）
7
type B = MaybeArray<number> // number（正确）

2. 真实场景：Axios 参数统一#

Axios 的params参数支持单个或多个值，比如id可以是 1 或[1,2]——用MaybeArray统一格式：

1
// 请求参数类型：id支持单个或多个
2
type RequestParams = {
3
  id?: number | number[]
4
  category?: string
5
}
6

7
// 统一参数格式：将所有值转为数组
8
function normalizeParams(params: RequestParams) {
9
  return Object.entries(params).reduce((acc, [key, value]) => {
10
    acc[key as keyof RequestParams] = Array.isArray(value)
11
      ? value
12
      : value
13
        ? [value]
14
        : []
15
    return acc
16
  }, {} as Record<keyof RequestParams, any[]>)
17
}
18

19
// 示例1：单个id
20
const params1 = { id: 123, category: 'electronics' }
21
const normalized1 = normalizeParams(params1) // { id: [123], category: ['electronics'] }
22

23
// 示例2：多个id
24
const params2 = { id: [123, 456], category: 'clothing' }
25
const normalized2 = normalizeParams(params2) // { id: [123,456], category: ['clothing'] }
26

27
// 用Axios发送请求（自动转换为id=123&id=456）
28
axios.get('/api/products', { params: normalized1 })

五、模板字面量类型：字符串的“格式锁”#

想避免路由/类名的拼写错误？比如把/home写成home，把bg-blue-700写成bg-blue-600——模板字面量类型能帮你“锁死”字符串格式。

1. 基础用法：约束动态路由#

React Router/Vue Router 的动态路由（比如/user/:id），可以用模板字面量类型约束：

1
// 动态路由类型：支持/user/:id（id为数字）和/product/:id（id为字符串）
2
type DynamicRoute = `/user/${number}` | `/product/${string}`
3

4
// 正确示例：
5
const userRoute: DynamicRoute = '/user/123' // ✅
6
const productRoute: DynamicRoute = '/product/abc' // ✅
7

8
// 错误示例：
9
const invalidUser: DynamicRoute = '/user/abc' // ❌（id必须是数字）
10
const invalidProduct: DynamicRoute = '/product/123' // ❌（id必须是字符串）

2. 真实场景：Tailwind 类名约束#

Tailwind 的类名有严格格式（比如bg-${color}-${shade}），用模板字面量类型约束：

1
// 定义Tailwind的颜色和shade
2
type TailwindColor = 'red' | 'blue' | 'green'
3
type TailwindShade = 500 | 700 | 900 // 设计系统只用这三个shade
4

5
// 约束背景颜色类名：bg-${color}-${shade}
6
type BgColorClass = `bg-${TailwindColor}-${TailwindShade}`
7

8
// 正确示例：
9
const primaryBtn: BgColorClass = 'bg-blue-700' // ✅
10
const dangerBtn: BgColorClass = 'bg-red-500' // ✅
11

12
// 错误示例：
13
const invalidBtn: BgColorClass = 'bg-red-600' // ❌（shade不在允许的范围内）
14
const invalidColor: BgColorClass = 'bg-purple-700' // ❌（color不在允许的范围内）

结语：TypeScript 的“进阶”是“用类型思维解决问题”#

这 5 个技巧的核心，不是“炫技”，而是把业务规则转化为类型约束：

用分布式条件类型过滤内部 Action，避免误操作；
用递归类型描述导航树/评论，避免重复定义；
用索引访问类型取深层字段，避免拼写错误；
用智能回退的条件类型统一 API 参数，避免格式混乱；
用模板字面量类型约束字符串，避免拼写错误。

TypeScript 的进阶，从来不是学更复杂的语法，而是学会用类型描述业务——把原来写在注释里的约定，变成编译器能检查的类型，让 bug 在编译时就被消灭。

慢慢来，先把这 5 个技巧用熟，你会发现：TS 真的越来越“懂”你的业务了～

音乐

音乐