学习一个成熟项目的架构，不应只盯着它今天的样子。怎么说呢，打开源码，看看模块如何划分、进程如何拆分、接口如何定义，当然很关键。但如果学习止步于此，我们得到的往往只是 What。也就是“术”：VS Code 使用了哪些模式，某类代码放在哪一层，模块之间怎样通信。

这些“术”，都是一个团队面对特定问题、在特定技术条件下给出的答案。话说回来，它们可以帮助我们读懂 VS Code。却未必能直接解决下一个程序的问题。换一个业务场景、团队规模或技术环境，照搬一样的模式，很可能就不再适用。

如果你想快速了解 VS Code 的架构演进。却只能看到代码变动而无法洞察决策动机，这让人困惑；而单纯看现状又难以预见未来。

约束，哪些技术已经成熟，哪些还没有？他们试过什么又为什么放弃？最终的选择解决了什么同时留下了什么代价？话说回来，

先把十年时间线摊开

如果把这十年压成一句话。大概是：

说到第一阶段，Monaco 先问的是“浏览器能否成为真正开发工具运行环境？”

VS Code 的起点不是 Electron，更不是桌面应用。在 年 VS Code 回顾里团队把最初的问题写得很清楚：因为浏览器开始支持 HTML5。JavaScript 引擎也越来越快，他们想试一试能否在浏览器里做出一款“用起来像原生应用”的代码编辑器。

至于你可能会问。既然是编辑器，该怎么保证性能与体验？这正是当年团队必须解决的问题，也是后续所有设计决策的根源。说起来，

为什么值得尝试？

• HTML5 能力继续增长
• JavaScript 运行时越来越快
• TypeScript 正在兴起，为大型 JavaScript 应用提供类型支持
• Mona 是可嵌入网页且功能比较全面的编辑内核。 为后续工作台提供基础

从 Monaco 到 Workbench 的成长轨迹

Mona Editor 最初仅是文本编辑主要，但团队为了日常开发需要，把文件树、搜索、调试等功能逐步集成进去，从而形成了完整工作台。其实，这一步并非一次性规划，而是基于实际使用需求不断迭代得到。

第二阶段的观点是，Electron 为何成为首选？

拥有 Web Workbench 后团队希望将其迁移到 Windows/macOS/Linux 上，让本地资源也能被访问。Electron 在那时刚出现，但已具备 Chromium 渲染 + Node.js 本地能力 + 跨网站窗口管理三大优势。说起来，

如果你曾尝试自己搭建跨网站桌面框架。你会感受到 Electron 提供的一站式方法带来的速度与成本优势；但也要警惕其安全和复杂度债务。

• Easiest path to cross-platform desktop.
• No major rewrites needed;just wrap existing web stack.
• Pushed out by quick iteration .

从第三阶段来看，Extension Host 与稳定 API 的诞生

Divergent needs: editors needed to be extensible。yet extensions had to be safe and stable. The team decided to expose a robust Extension API and n build core features as extensions mselves.

想让社区贡献插件，却担心插件会影响主程序稳定性，这是许多 IDE 开发者共同痛点。Extension Host 的多进程设计正是为了解决这个痛点而产生。

• Main idea: “If even our own core cannot be implemented via this API,it’s not ready for third parties.”
• User-level isolation: Extensions run in separate processes,preventing crashes from blocking UI.
• LSP support: Language Server Protocol decouples language logic from editor implementation.

Extension Host 与远程开发交叉点

The same process boundary that isolated local extensions also enabled moving m to remote machines later on—precisely what Remote Development required.

从第四阶段来看。Language Server Protocol的出现——让语言工具跨编辑器共享

• A protocol defined by multiple teams enabling any language server to talk to any editor via JSON‑RPC.
• This avoided rewriting every language tool per editor and allowed sharing across editors.
若你的项目已有自定义语言服务器，但目前只能在单一 IDE 中使用，通过 LSP 可以轻松迁移到 VS Code 或其它支持 LSP 的编辑器，从而提高维护成本与使用者体验。
• Decouples editor from language logic. Supports multiple programming languages. Enables cross‑editor reuse. Requires careful versioning & compatibility management. Adds overhead for message serialization & state sync. .

至于第五阶段。Remote Development——由使用者逼出的远程工作区拆分需求

• Bare-metal local vs WSL/containers/VMs – developers needed consistent environment across platforms.
• The solution was a dual‑process architecture: UI stays local while file system,terminal,debugger,language tools run remotely.
若你的团队频繁切换容器或云端环境，你会发现传统 IDE 无法利用这些资源；Remote Development 把这一痛点转化为可操作方案。

第六阶段这方面。vscode.dev——从 Monaco 到 Web Workbench 再到全栈 Web IDE

• The web version leverages modern browser APIs and cloud backends . It is not just a copy of desktop – it’s an adaptation with explicit capability boundaries.
若你想在无安装IDE的大型会议或教育场景中部署 VS Code，只需打开浏览器即可访问完整功能，而不会被本地终端或调试限制所束缚。这正解锁了之前不可实现的新场景需求。

“我们把‘当前工作区是否可信’提高为 Workbench 和 Extension API 都能读取的全局状态。” 未信任工作区会进入 Restricted Mode，任务、调试等可能执行代码的能力都会受到限制。老实说，

当安全模型变化时如果你只依赖渲染进程直接调用 Node.js。那就可能导致恶意脚本获取程序权限。此类安全债务往往需要重写大量 IPC 和进程边界才能修复。