一句话定义：Type Server Protocol（类型服务器协议）是微软在 Language Server Protocol（LSP，语言服务器协议）基础上扩展出的一套通信约定，用来让编辑器和"类型服务器"（type server）对话，把类型检查、类型推断这类重活从编辑器插件里搬到一个独立进程里干。
先打个比方
传统编辑器里的类型提示，像每位程序员都雇了一位私人医生坐在旁边：你敲一个变量名，插件立刻在本机算它是什么类型。问题是这位"医生"住在编辑器进程里——代码库一大，他就开始喘；插件一崩，编辑器跟着卡；换个编辑器，得重新雇一位。
类型服务器更像"医院检验科"：抽血化验的活集中到一个独立科室，患者（编辑器）只负责送样本、取报告。科室可以服务很多人，可以单独升级设备，也可以被别的系统复用。
它到底解决什么
三个具体痛点：
一是启动与内存。 打开一个大型 TypeScript 项目，插件要在编辑器进程内加载整个项目、建立符号索引。放进独立进程，编辑器启动更快，卡死也只死一个子进程。
二是复用。 同一个类型服务器可以同时服务编辑器、CI 检查、代码审查工具、甚至 AI 编码助手——大家用同一份类型结论，而不是各算各的、算出不同答案。
三是解耦。 类型能力不再绑死在某个编辑器插件里。插件只管 UI 和交互，类型语义由服务器负责，两边可以分别演进。
和 LSP 是什么关系
LSP 解决的是"编辑器怎么问一个语言服务器要补全、跳转、诊断"；Type Server Protocol 关注的是语言服务中更窄也更重的一块：类型系统。可以理解成 LSP 的专门化延伸——消息模型同源，但请求内容更贴近类型的语义，比如"这个位置的符号是什么类型""这个表达式的推断结果是什么""请给出这一处的类型诊断"。多出来的部分需要更细的类型信息和更长的计算时间，所以才值得单独拉一个服务出来。
| 维度 | LSP | Type Server Protocol |
|---|---|---|
| 覆盖范围 | 通用语言能力：补全、跳转、格式化、诊断 | 聚焦类型：类型查询、推断、类型级诊断 |
| 典型实现 | 各语言各自的 language server | TypeScript 生态里的 tsserver 一类 |
| 复用对象 | 多个编辑器 | 编辑器之外，还有 CI、审查工具、AI 助手 |
| 关系 | 基础协议 | 在其之上做类型方向的扩展 |
需要说明的是，这套协议仍在演进，具体消息名、能力协商的细节以微软官方文档与 TypeScript 仓库为准。
怎么接进来
对编辑器或 IDE 作者：写一个客户端，负责启动类型服务器进程、按协议完成初始化握手、把用户的编辑动作转成请求发出去，再把返回的类型信息渲染成悬浮提示或下划线。
对工具作者：要么实现一个符合协议的服务器，要么直接复用现成的 tsserver，把它当子进程拉起。常见做法是通过扩展或插件的设置项指定服务器可执行文件的路径，让工具自己找到它。
对普通职场人：你不需要读协议。但你能感受到结果——大型项目里补全和报错变快了，AI 编程助手给出的类型建议和编辑器显示的一致了，而不是各说各话。这背后就是"类型检查被抽成一个服务"在起作用。