跳到主要内容

TypeScript 在 Node.js 项目中的渐进式落地

· 阅读需 2 分钟
一介布衣
一介布衣
全栈开发者 / 技术写作者

2021 年的 Node.js 项目里，如果还完全不谈 TypeScript，多少会开始显得有点吃力。项目一大、接口一多、团队一扩，人肉靠约定来维持字段一致性，很快就会出问题。

但我也不赞成那种“把老项目一把梭全改成 TypeScript”的思路。更稳的做法，通常是渐进式落地。

为什么 Node.js 项目越来越需要类型​

后端项目最常见的混乱，并不是语法，而是数据结构：

  • 接口参数长什么样
  • service 返回值长什么样
  • 配置项到底有哪些
  • 某个字段到底能不能为 null

TypeScript 在这里最有价值的地方，就是让这些约定提前暴露出来。

最适合先接入的三个位置​

如果是已有项目，我会优先从下面三块开始：

  • 接口 DTO
  • 配置对象
  • 核心 service 返回值

因为这三类地方一旦类型清楚，项目里很多“猜字段”的成本会立刻下降。

type CreatePostPayload = {
  title: string;
  summary: string;
  content: string;
  tags?: string[];
};

type PostListItem = {
  id: number;
  title: string;
  slug: string;
  publishedAt: string | null;
};

渐进式接入比全面改造更现实​

比较适合团队的推进方式通常是：

  1. 允许 JS 与 TS 共存
  2. 新模块优先用 TS
  3. 边改业务边补类型

这样既不会把重构成本一下推到最高，也能逐步把收益吃到。

不要把类型写成另一套负担​

TypeScript 的坑也很明显：一旦过度设计，类型本身会比业务还难懂。我的经验是，Node.js 项目里的类型要服务于边界清晰，而不是追求“类型体操”。

所以最重要的是：

  • 先把输入输出写清楚
  • 再补关键业务对象
  • 最后再考虑更复杂的泛型抽象

小结​

TypeScript 在 2021 年已经不只是“更严谨一点”的选择了，它开始成为团队协作成本控制的一部分。对 Node.js 项目来说，渐进式接入是最务实、也最容易被团队接受的路线。