[!info] related notes

• 所属 MOC: TypeScript MOC
• 总览页: TypeScript
• 相关概念: TypeScript 中的 strict, TypeScript 中的声明合并
• 相关调试: TypeScript 中 no-unsafe-declaration-merging 报错排查
• 相关工具: tsc, TypeScript 语言服务与 tsserver

TypeScript 类型检查

范围

这篇笔记讨论的是 TypeScript 类型检查的整体结构：它由哪些机制组成，哪些由 tsc 负责，哪些由语言服务负责，哪些又其实是 ESLint 在管。

为什么要放在一起理解

很多“TypeScript 报错”其实来源不同：

• 有的是类型系统本身的错误
• 有的是 tsconfig 造成的项目边界问题
• 有的是编辑器语言服务给出的语义诊断
• 有的是 @typescript-eslint 规则在报警

如果把它们都混成一种“TS 报错”，就很难判断该从哪里修。

依赖路径 / 调用链 / 演进链

一个典型的检查链条通常是：

1. 代码被 TypeScript 类型系统解释
2. tsc 或 tsserver 基于 tsconfig 构建 program
3. 类型错误、模块解析错误、声明文件错误被报告出来
4. ESLint 再在类型信息之上叠加额外规则

也就是说，ESLint 里的部分 TypeScript 规则经常依赖 TypeScript 已经先把代码理解好了。

对比与易混淆点

TypeScript 类型检查 vs 运行时校验

• TypeScript：编译阶段保证“类型应该如何被理解”
• 运行时校验：处理外部数据是否真的满足这个结构

TypeScript 类型检查 vs ESLint

• TypeScript 负责类型语义
• ESLint 负责规则治理、风险模式和风格约束

比如 no-unsafe-declaration-merging 这类报错，表面上和 TypeScript 类型有关，但实际是 ESLint 在提示这段写法的维护风险。

编辑器红线 vs 命令行报错

两者不一定来自同一版本、同一上下文。先确认：

• 用的是哪一版 TypeScript
• 用的是哪个 tsconfig
• 报错来自 tsc 还是 ESLint