Zed编辑器，用Rust和GPU重构的代码编辑体验，让大型项目秒开

作者提米哥

如果你还在忍受 VS Code 打开大型项目时那几秒钟的卡顿，Zed 这个编辑器可能值得你花两分钟了解。它用 Rust 语言重写了底层，直接调用 GPU 渲染界面——不是那种“优化过的 Electron 壳”，而是从头造了一个原生框架。

我拿一个有三十万行 TypeScript 代码的 monorepo 试了一下：VS Code 启动要 8 秒才能把索引跑完，每次全项目搜索又要等 2~3 秒。Zed 第一次打开不到 1 秒就把索引建好了，搜索结果的展示速度比我打完搜索关键词还快。

这种“无妥协的速度”正是 Zed 存在的理由。它的作者 Nathan Sobo 和 Max Brunsfeld 十年前在 GitHub 做了 Atom 编辑器，后来被 VS Code 的生态和性能压过，于是第二版直接换了个思路——用 Rust 写、用 GPU 渲染、把延迟当成设计约束而不是事后优化。这不是把 Web 框架压一压性能，而是换了一套底层架构。

架构：为什么 Zed 的感觉不一样

Zed 的基本原理：它自己搞了一套叫 GPUI 的图形框架，每个像素通过 GPU 渲染，而不是像 VS Code 那样走 DOM 渲染器。每次按键都由自定义的文本缓冲区引擎处理，而不是在 Electron 里跑一个 Monaco 编辑器实例。

实际体验上，最明显的三个地方是启动速度、大文件处理、搜索。
– 启动时间：在我 M2 MacBook Air 上，Zed 大约 200 毫秒弹出来。VS Code 通常要 2~4 秒。虽然差的不多，但对我而言，以前因为重启成本高，VS Code 开了一整天不关；现在用 Zed，关掉重开都不觉得亏，因为那点延迟根本感觉不到。
– 大文件：打开一个 50MB 的日志文件，VS Code 会警告并卡几秒；Zed 瞬间打开，语法高亮和滚动位置都正常。它的文本缓冲区用了块表（Piece Table）数据结构——就是 Sublime Text 当年那个方案——专为日常频繁的增量编辑优化。
– 滚动流畅度：GPUI 通过 GPU 绘制文本，包括滚动。5,000 行文件滚动起来跟原生 macOS 应用一样丝滑，因为 Zed 在 ProMotion 屏幕上能跑到 120 帧。VS Code 的 Electron 渲染器最多 60 帧，复杂文件还会掉帧。别小看这一点——长时间编码时，眼睛疲劳感会少很多。

语言支持：好东西和妥协

Zed 对主流语言的语言服务器（LSP）集成更激进，但生态不如 VS Code 成熟。它自带 Rust、TypeScript、Python、Go 等十几种语言的支持，每个都有 tree-sitter 语法高亮和预配置的 LSP。以 TypeScript 为例，智能提示、跳转定义、查找引用、重命名——一切从第一次按键开始就能用，不用装任何扩展。

但问题在于小众语言。VS Code 市场里有数万种扩展，安装只需两下点击；Zed 的社区扩展大约只有 200 个。对于 Ruby、PHP、Swift、Kotlin 这些主流语言，体验没问题；但如果你写 Nim、Zig、OCaml、Elm，可能连语法高亮都找不到。

Rust 值得单独说。Zed 团队自己写 Rust，所以把 Rust 体验当成头等大事。rust-analyzer 的集成比 VS Code 更快——补全弹出延迟只有个位数毫秒，而 VS Code 通常要上百毫秒。内联类型提示、生命周期省略标注、宏展开预览，都感觉像原生 IDE 功能而不是 LSP 接口。如果你职业写 Rust，仅这一点可能就值了。

配置方面，Zed 用 JSON 文件 ~/.zed/settings.json，可选项比 VS Code 少很多。以下是一个典型配置：

// 主题与字体
{
  "theme": "One Dark",
  "ui_font_size": 16,
  "buffer_font_size": 15,
  "buffer_font_family": "JetBrains Mono",
  // 启用 Vim 模式
  "vim_mode": true,
  // 焦点离开时自动保存
  "autosave": "on_focus_change",
  "tab_size": 2,
  "soft_wrap": "editor_width",
  // LSP 配置示例：让 rust-analyzer 用 clippy 检查
  "lsp": {
    "rust-analyzer": {
      "initialization_options": {
        "check": { "command": "clippy" }
      }
    }
  }
}

设置项少不见得是坏事——默认值合理，你少了很多纠结。但如果你习惯把 VS Code 的每个角落都定制过，换个编辑器的确要放手一些东西。

协作：不用开浏览器就能实时结对

Zed 的协作功能是它最激进的一步。通过“频道（Channels）”，你可以把项目实时共享给队友，每个人的光标和编辑都实时可见。底层用了 CRDT（无冲突复制数据类型），而不是操作变换，所以是点对点传输，不需要中央服务器转发每次按键。

我测试了一下：和一个同事用 Rust 项目结对两个小时。体验跟 VS Code 的 Live Share 差不多——光标瞬间出现，编辑没有明显延迟，跟视图模式（跟着别人屏幕滚动）也很顺。优势是协作功能直接内建在编辑器架构里而不是扩展；劣势是对方也得装 Zed，没有网页版访客模式。

频道还支持文字聊天和屏幕分享，声音通话也有，但质量一般——应急用还行，专业开会还是得用其他工具。不过对于快速结对的场景，你不必在编辑器和其他 App 之间来回切换了。

Zed vs VS Code vs Cursor：2026 年的开发者编辑器地图

VS Code 依然是大多数人的默认选择，理由也很硬：扩展市场、调试体验、内置终端。如果你的工作流依赖 Docker 管理、数据库查看、API 测试、云服务集成这些扩展，那 VS Code 的生态目前无人能敌。

Cursor 是从 AI 方向切入的——它实际上是 VS Code 的一个分支，把 AI 补全、内联编辑、聊天深度整合到编辑器里。Zed 虽然有 AI 助手（通过 API key 配置），但只是个聊天面板，远不如 Cursor 那种能理解你整个代码库的内联编辑。如果你的核心工作是 AI 辅助编码，Cursor 更强。

Zed 拼的是另一条路：原始性能、原生手感、协作。它适合那些每次 VS Code 打开文件或弹出补全时感觉“有一丁点延迟”的开发者；适合想要工具链和编译器一样快的 Rust 开发者；适合不想再管理一个结对服务的团队。

如果你的工作流依赖 Zed 里没有的扩展——比如 Docker 管理、GitHub Copilot Chat（2026 年中这个还没有）、数据库浏览器、云厂商工具——那就把 VS Code 留着，当“开发环境”用，把 Zed 当“代码编辑器”用。两者分工，很合理。

谁该换到 Zed

用了四周后，我自己把 Zed 当成 Rust、TypeScript 和 Markdown 的主力编辑器，但 VS Code 依然留着用来管理数据库、Docker 以及那些依赖扩展的活。

最值得换的开发者：
– Rust 开发者——工具链集成是目前最好的
– 大型 monorepo 开发者——启动和搜索速度的差距随代码量放大
– 频繁结对编程的团队——内建协作省掉第三方服务，免费

暂时不用换的：
– 深度依赖 VS Code 扩展生态的
– 靠 AI 辅助编码且 Cursor 做得更好的
– 主力语言在 Zed 中 LSP 支持还不成熟（比如小众语言）

换编辑器没有奖。Zed 是开源项目，每个月都在改进，等几个月再试也没什么成本。

微信联系：timidamen

类似文章