TypeScript
TypeScript 主题总览，说明语言本体、类型系统、编译器、配置系统与语言服务之间的基本结构。
#tech / dev
#resource / typescript
#type / concept
#status / growing
TypeScript
[!info] related notes
一句话定义
TypeScript 是 JavaScript 的静态类型系统与工具链集合，它在不改变 JavaScript 运行时本质的前提下，为大型代码库提供类型检查、编辑器智能能力和更稳定的工程边界。
核心结构
理解 TypeScript，至少要分清 4 个层次：
- 语言与类型系统
- 编译器
tsc - 配置系统
tsconfig.json - 语言服务与
tsserver
语言与类型系统
这是 TypeScript 最直接的一层，负责表达：
- 基础类型与对象类型
- 联合、交叉、泛型
- 条件类型、映射类型、工具类型
- 类型推断与类型收窄
这一层回答的是：
代码在编译阶段应该被理解成什么类型。
tsc
tsc 是 TypeScript 编译器。它负责：
- 读取源码和
tsconfig - 做类型检查
- 生成 JavaScript、
.d.ts、sourcemap - 在 build mode 中处理 project references
这一层回答的是：
这些 TypeScript 文件如何被编译和验证。
tsconfig.json
tsconfig 用来定义一个 TypeScript program 的边界和编译规则，例如：
- include / exclude
- strict
- module / target
- paths / baseUrl
- declaration / composite / references
这一层回答的是：
TypeScript 应该以什么规则理解和构建这个项目。
语言服务与 tsserver
编辑器里的这些体验通常来自 TypeScript 语言服务：
- hover
- 跳转定义
- 自动补全
- quick fix
- 语义诊断
tsserver 则是把这些能力提供给 VSCode 等编辑器的后台服务。
这一层回答的是：
编辑器为什么知道这里是什么类型，为什么这里会出现红线。
为什么要按结构理解
很多 TypeScript 问题，本质上不是“语法不会”，而是混淆了不同层次：
- 以为类型系统能解决运行时校验
- 以为
paths配了就等于运行时 alias 也配好了 - 以为编辑器报错和命令行报错一定来自同一套上下文
- 以为
tsc、bundler、ESLint 都在做同一件事
一旦把语言、编译器、配置和语言服务分开看，很多问题会明显简单很多。
常见学习路径
推荐按这个顺序进入：
- 先掌握基础类型、联合类型、泛型、类型收窄
- 再理解
tsc、tsconfig和严格模式 - 再进入声明文件、全局扩展、
import type等边界话题 - 最后再看 monorepo、project references、编辑器诊断差异
边界与易混淆点
TypeScript 不是运行时验证器
TypeScript 主要工作在编译阶段。它可以表达“应该是什么类型”，但不能替代：
- 运行时数据校验
- API 输入校验
- 用户输入可信度判断
TypeScript 不是打包器
tsc 能编译，但不等于现代前端项目的完整构建链。代码拆分、资源处理、HMR、产物优化通常仍要靠 bundler 或框架工具链。
TypeScript 也不是 ESLint
TypeScript 负责类型语义；ESLint 负责代码风格、部分风险模式和规则治理。两者经常一起出现，但职责不同。