tsc --noEmit：即时类型反馈

类型检查不需要构建

当你写完一段 TypeScript 代码，想知道类型是否正确，你不需要运行完整的构建流程。

构建包含了太多东西：编译、打包、优化、生成文件。这些都需要时间。而你只想要一个答案：类型对不对。

类型检查是独立的。它不产生文件，不执行代码，只分析类型关系。

最简单的命令

tsc --noEmit

这个命令做一件事：检查类型，不输出文件。

--noEmit 告诉 TypeScript 编译器：我不需要生成 JavaScript 文件，只需要类型分析报告。

如果有类型错误，你会立即看到。如果没有，命令静默完成。

没有副作用，没有文件生成，没有额外开销。纯粹的类型验证。

为什么要分离类型检查

开发工具链越来越复杂。webpack、vite、next.js，每个构建工具都有自己的编译流程。

这些工具确实会检查类型。但它们的主要目的是构建，不是类型检查。

类型错误混在构建日志里，夹杂着依赖解析、模块打包、资源优化的信息。你需要在大量输出中找到那几行类型错误。

而 tsc --noEmit 只做类型检查。输出是干净的。要么没有输出（通过），要么只有类型错误（失败）。

专注产生清晰。

Watch 模式：持续反馈

tsc --noEmit --watch

加上 --watch，类型检查器持续运行。

你修改文件，保存，立即看到类型错误更新。

这是最短的反馈循环。不需要手动重新运行命令，不需要等待构建，不需要刷新页面。

代码改动 → 类型检查 → 错误显示，整个过程在几百毫秒内完成。

这种即时性改变开发体验。类型错误不再是"构建失败的原因"，而是"编码过程中的实时提示"。

在 Claude Code 中集成

Claude Code 可以运行 shell 命令。这意味着类型检查可以随时发生。

当你要求 Claude 修改代码时，你可以立即要求运行类型检查：

tsc --noEmit

如果有错误，Claude 看到具体的类型错误信息，可以立即修正。

如果没有错误，你知道改动是类型安全的。

这不是在"最后检查一下"。这是在每次改动后立即验证。

tsc --noEmit --project ./path/to/tsconfig.json

错误输出的价值

类型错误不是障碍，是信息。

src/user.ts:15:7 - error TS2339: Property 'email' does not exist on type 'User'.

15   user.email.toLowerCase()
         ~~~~~

这个输出告诉你：

文件位置： src/user.ts:15:7 - 第 15 行第 7 列

错误类型： TS2339 - 属性不存在

问题描述： Property 'email' does not exist on type 'User'

代码上下文： 直接显示出错的那一行

这不是模糊的"构建失败"。这是精确的诊断。

你不需要猜测哪里出错。错误消息指向具体位置，说明具体问题。

在 Claude Code 中，Claude 可以直接读取这些错误，定位到文件的具体行，修正问题。

类型检查的时机

类型检查应该在什么时候发生？

写完一个函数后。 立即验证参数类型、返回值类型是否正确。

重构代码时。 改动接口定义、修改函数签名，类型检查告诉你哪些调用处需要更新。

添加新依赖后。 第三方库的类型定义可能不完整或有错误，类型检查能暴露这些问题。

提交代码前。 确保没有类型错误混入版本控制。

CI 流程中。 自动化检查，阻止不符合类型安全的代码合并。

但最重要的时机是：随时。

因为 tsc --noEmit 足够快，你不需要等待特定时机。想检查就检查。

与运行时验证的关系

类型检查解决编译时的类型一致性。它不能保证运行时数据的正确性。

外部数据——API 响应、用户输入、环境变量——不受 TypeScript 类型系统约束。

这需要运行时验证。参考 runtime-type-contract 了解如何在边界处延续类型契约。

类型检查和运行时验证是两层防护：

编译时类型检查： 确保你的代码逻辑在类型层面是自洽的。

运行时验证： 确保外部数据符合你的类型假设。

两者结合，才是完整的类型安全。

最后

类型检查不需要等待。tsc --noEmit 给你即时反馈。

构建是为了输出，类型检查是为了验证。分离两者，清晰各自的目的。

在 Claude Code 中，随时运行类型检查。每次改动后立即验证。

类型错误越早发现，修复成本越低。最好的发现时机是写完代码的那一刻。

工具已经存在。剩下的是使用习惯。