你 Dev Stack 中最重要的工具是你从未听说过的
Source: Dev.to
请提供您想要翻译的文章正文内容，我将为您翻译成简体中文并保持原有的格式。
你看到的 vs. 实际发生的
“Initializing JS/TS language features…”
VS Code 状态栏中那个小小的旋转图标不仅仅是加载动画，它是 编辑器智能的心跳。
- Hover（悬停）在函数上 → 查看其类型签名。
- Ctrl + click（Ctrl + 点击） → 跳转到定义。
- Rename（重命名）符号 → 在整个代码库中同步更改。
这些看起来像是 VS Code 的内置功能，但其实 不是。它们全部来自后台运行的另一个程序：
| Feature | Source |
|---|---|
| Hover info | tsserver |
| Go‑to‑definition | tsserver |
| Auto‑completions | tsserver |
| Error squiggles | tsserver |
| Rename refactoring | tsserver |
tsserver 是一个 language server，它通过 Language Server Protocol (LSP) 与 VS Code 通信。VS Code 只充当信使，真正的智能在别处。
Pre‑LSP 时代（2016 年之前）
- 每个编辑器都必须从头实现语言支持。
- 想在 Vim 中使用 TypeScript？为 Vim 构建一个 TypeScript 插件。
- 想在 Sublime Text 中使用 TypeScript？再构建一次。
- 相同的工作在每种语言和每个编辑器中都要重复一次。
Result:
- 大多数编辑器的语言支持平平。
- 少数编辑器对少数语言提供了出色的支持。
- 开发者被迫使用恰好拥有体面工具的编辑器。
它是一团缓慢、支离破碎、重复的混乱。
LSP 的诞生 (2016)
Microsoft 引入了 语言服务器协议（Language Server Protocol），其核心理念很简单：
将编辑器与语言智能分离。
- 编辑器：负责文本渲染、标签页、用户界面等。
- 语言服务器：提供特定语言的分析功能。
通信仅通过标准协议的 JSON 消息实现：
// 编辑器请求
{
"method": "textDocument/hover",
"params": {
"textDocument": "...",
"position": { "line": 42, "character": 15 }
}
}
// 语言服务器响应
{
"contents": "function processOrder(cart: CartItem[]): Promise"
}编辑器不需要了解 TypeScript，语言服务器也不必知道你使用的是哪个编辑器。
为什么这被称为编辑器的 “HTTP 时刻”
- HTTP 之前：浏览器需要为每个服务器编写专用的客户端软件。
- HTTP 之后：任何浏览器都能与任何服务器通信 → 网络迎来了爆炸式增长。
LSP 为开发者工具做了同样的事：统一协议，统一生态。
Source:
强强联手：VS Code + tsserver
tsserver可以说是有史以来最复杂的语言服务器。- VS Code 被设计为轻量、快速的 LSP 客户端。
当你在 VS Code 中打开一个 TypeScript 项目时，你会得到：
- 即时的类型信息。
- 智能的自动导入。
- 跨文件的重构。
- 实时错误检测（甚至在保存之前）。
这些并不是 VS Code 的“聪明”之处，而是 tsserver 在背后完成了繁重的工作，VS Code 只是一位完美的客户端。
由于通信标准化，同一个 tsserver 也可以在 Neovim、Helix、Emacs、Sublime 等编辑器中使用。VS Code 只是成为了最顺畅的客户端，从而在“编辑器之争”中脱颖而出。
AI 编码工具也是 LSP 客户端
类似 Cursor、Continue、GitHub Copilot、Cody、Windsurf 等工具：
- 发送 LSP 请求（例如 hover、definition、diagnostics）以获取结构化上下文。
- 将该上下文提供给大型语言模型（LLM）。
- 获取更智能的建议（重构、补全等）。
AI 并 未 替代 LSP；它 基于 LSP 构建。
TL;DR
- 旋转的图标是
tsserver正在启动，解析你的整个项目。 - LSP 将编辑器与语言智能分离，就像 HTTP 将浏览器与服务器分离一样。
- VS Code 的成功源于它是最佳 LSP 客户端，配合最佳语言服务器。
- 现代 AI 编码助手依赖 LSP 来获取所需的结构化理解。
下次看到加载旋转图标时，请记住：你正在目睹 驱动现代开发者工具的引擎。 🚀
The Unsung Hero of Modern Development: Language Server Protocol (LSP)
“最具变革性的基础设施并不是那些上头条的，而是那些消失在背景中的——如此隐形、如此可靠，以至于你忘记它的存在。直到你意识到，你所依赖的一切都是建立在它之上的。”
为什么 AI 编码工具如此受热捧？
- 哪种 LLM 编写的代码更好？
- 代理会取代开发者吗？
所有这些噪音掩盖了一个已有九年历史、默默承担重任的协议：基于 JSON‑RPC 的 语言服务器协议。
LSP 实际做了什么
- 保证 第47行的 user 与 第12行定义的 user 是同一个。
- 确保在一个文件中重命名函数不会导致其他地方的 import 失效。
- 在 毫秒 级别向代理提供类型签名，支持智能建议。
简而言之，LSP 将代码智能转变为 开放、可组合的基础设施——不再局限于单一编辑器或由单一公司所有。它成为编辑器、插件和 AI 代理都能平等构建的共享基础。
Real‑World Impact
- 在拉各斯的自由职业开发者使用 Neovim，获得与谷歌的资深工程师使用 VS Code 相同的 TypeScript 智能提示。
- 一个全新的 AI 初创公司享受与 GitHub Copilot 相同的结构化代码理解能力。
这就是 LSP 所带来的成果：为代码智能提供公共设施，而不仅仅是编辑器与语言服务器之间的连接器。
要点
下次当你的编辑器神奇地理解你的代码，或是 AI 代理提出的重构真的有效时，留意状态栏中的那个小加载图标，并感谢在 2016 年悄然成为开发者工具 HTTP 的协议。
我自豪的项目
- Voice‑Controlled IDE (16 天) – “我的声音现在是编辑器。”
- Anime‑Inspired VS Code Theme Bundle – “受 17 世纪日本艺术启发。”
您可以在我的 GitHub Copilot Competition 提交中浏览这两个项目：
关于我
我撰写关于 AI 工具、开发者工作流，以及当技术变得易于获取时谁掌握权力 的内容。
- 📧 订阅 我在 Substack 上的每周深度探讨
- 🐦 关注 我在 X（前身为 Twitter） 上的短篇分享和幕后洞见
感谢阅读。愿语言服务器协议继续在后台静默运行，让我们开发者的生活更轻松。