TypeScript 中最容易被滥用的 10 个特性-X记录空间

前言

TypeScript 已经成为现代前端开发的重要组成部分。

但很多团队虽然使用了 TypeScript，实际上却没有真正发挥它的价值。

甚至因为错误的使用方式，让代码变得比 JavaScript 更难维护。

本文不会介绍基础语法，而是总结在大型项目中最容易被滥用的 10 个 TypeScript 特性，并结合工程实践给出更合理的建议。

1. any：最危险的类型

很多人遇到类型报错时：

第一反应：

const data: any = response;

问题确实解决了。

但同时：

整个类型系统也失效了。

一旦 any 开始扩散：

类型检查就会越来越弱。

建议：

只有在：

第三方 SDK。

动态数据。

历史代码迁移。

等特殊场景下使用 any。

否则：

优先考虑：

unknown。

2. unknown 才是默认选择

相比 any。

unknown 更安全。

因为：

必须先判断。

才能使用。

例如：

if (typeof value === "string") {
  console.log(value.toUpperCase());
}

这样：

类型收窄之后。

IDE 依然可以提供完整提示。

3. interface 和 type 不要混用

很多团队没有统一规范。

例如：

interface User {}

type User = {}

长期来看。

维护成本很高。

4. enum 并不适合所有项目

enum 曾经非常流行。

但现代项目：

越来越倾向：

const STATUS = {
  SUCCESS: "success",
  FAIL: "fail"
} as const;

原因：

Tree Shaking 更好。

推导更自然。

运行时代码更少。

5. 泛型不是越复杂越好

很多人喜欢：

写：

四五层泛型。

实际上：

阅读成本非常高。

泛型应该：

解决重复。

而不是：

炫技。

6. Utility Types 不要滥用

例如：

Partial

Pick

Omit

Record

确实很好用。

但：

嵌套太深。

会让类型越来越难读。

7. 类型断言不是修复工具

很多人：

data as User

其实：

只是：

告诉编译器：

“相信我。”

它不会做任何运行时校验。

如果数据来源不可信。

应先验证。

再断言。

8. infer 很强，但不是必须

infer 可以实现：

非常复杂的类型推导。

但：

普通业务开发。

真正需要 infer 的地方并不多。

团队维护时：

可读性通常比技巧更重要。

9. satisfies 值得关注

相比：

as

现代 TypeScript 更推荐：

satisfies

它既能校验类型。

又不会丢失字面量信息。

非常适合：

配置对象。

常量定义。

10. 类型系统不能替代运行时校验

这是很多开发者最容易忽略的一点。

TypeScript：

只存在于编译阶段。

接口返回的数据。

用户输入的数据。

都可能不符合类型。

因此：

重要数据仍然需要：

运行时校验。

例如：

Zod。

Valibot。

ArkType。

等方案。

大型项目的建议

真正优秀的 TypeScript 项目。

不是：

类型最复杂。

而是：

类型最容易理解。

建议：

保持命名一致。
减少 any。
优先使用 unknown。
控制泛型复杂度。
保持 interface 与 type 的统一规范。
配合运行时校验。

总结

TypeScript 的目标不是增加代码量。

而是帮助开发者在编译阶段发现问题。

真正好的类型设计，应当服务于可读性、可维护性和团队协作，而不是追求炫技。

随着项目规模扩大，一个清晰、稳定的类型系统，往往比复杂的高级类型技巧更有价值。

TypeScript 中最容易被滥用的 10 个特性

前言