[!info] related notes

• 所属 MOC: TypeScript MOC
• 前置概念: TypeScript, tsc
• 并列概念: TypeScript 中的 baseUrl 与 paths
• 易混淆概念: vscode的TS-JS语言服务频繁崩溃问题
• 关系笔记: TypeScript、tsc、tsconfig 与 tsserver 的关系, 编辑器、TypeScript 版本与 tsconfig 诊断结果的关系

TypeScript 语言服务与 tsserver

一句话定义

TypeScript 语言服务负责“理解代码并提供编辑器智能能力”，tsserver 则是把这些能力通过协议暴露给编辑器或 IDE 的独立服务进程。

核心机制 / 工作原理

TypeScript 语言服务负责什么

编辑器里这些能力，通常都来自 TypeScript 语言服务：

• 补全
• 悬浮提示
• 跳转定义
• 重命名
• quick fix
• 语义诊断

也就是说，编辑器看到的红线、hover 和 auto import，不只是“文本规则”，而是 TypeScript 对当前项目做了一次程序级理解之后给出的结果。

tsserver 是什么

根据 TypeScript 官方 wiki，tsserver 是一个独立的 Node 可执行程序，它封装了编译器与语言服务，并通过 JSON 协议和编辑器通信。

可以把它理解成：

• tsc 更像命令行编译器
• tsserver 更像给编辑器用的长期驻留后台服务

为什么编辑器诊断和命令行结果可能不一样

即使都叫“TypeScript 报错”，来源也可能不完全相同：

• 编辑器可能连的是某个版本的 tsserver
• 终端里运行的是另一个版本的 tsc
• 编辑器打开项目时，识别到的 tsconfig、插件、工作区边界也可能不同

所以“VSCode 有红线，但命令行没报错”并不必然意味着谁错了，先确认双方是不是用的同一版本、同一项目上下文。

最小例子 / 最小场景

一个常见误判

现象：

• VSCode 对 tsconfig.json 给出弃用提示
• pnpm exec tsc -v 对应的本地 TypeScript 版本还没触发同样的提示

这时更接近的解释通常是：

• VSCode 的语言服务版本更高
• 编辑器和命令行没有用同一套 TypeScript

而不是“同一个 TypeScript 在同一上下文里给了两个不同答案”。

边界与易混淆点

语言服务不是构建系统

语言服务擅长回答：

• 这里是什么类型
• 这个 import 能不能解析
• 这里为什么有错误

但它不等于完整构建流程。真正产出 JS、.d.ts、sourcemap、打包结果，仍然要看：

• tsc
• bundler
• 框架构建链

tsserver 不等于所有编辑器都完全一样

很多编辑器都会复用 TypeScript 的语言服务能力，但接入方式不一定一样：

• 有的直接用官方 tsserver
• 有的包一层自己的语言客户端
• 有的只做部分配置校验

所以不同编辑器对同一文件的报错行为，既可能受 TypeScript 版本影响，也可能受接入方式影响。

参考信息

• TypeScript Wiki: tsserver: https://github.com/microsoft/TypeScript/wiki/Standalone-Server-%28tsserver%29
• VS Code TypeScript editing: https://code.visualstudio.com/docs/typescript/typescript-editing
• VS Code JavaScript support: https://code.visualstudio.com/docs/nodejs/working-with-javascript