Zed 编辑器：Rust 重写的多人协作代码编辑器，性能与协作的取舍
由 Atom 与 Tree-sitter 的作者用 Rust 打造的高性能多人协作代码编辑器，支持 macOS、Linux 与 Windows。
秒懂
- 它是什么？
- Zed 是一款用 Rust 编写的高性能多人代码编辑器，由 Atom 和 Tree-sitter 的创造者开发。本文基于其公开仓库与文档，分析其核心机制、安装方式、许可证约束，并指出它在协作功能上的局限与适用场景。
- 适合谁用？
- Zed 适合追求低延迟编辑体验、愿意接受 GPL-3.0-or-later 许可证约束的 Rust 或系统级开发者，尤其是那些重视多人实时协作的团队。不适合需要 Web 端支持或依赖大量成熟插件生态的用户，因为 Web 版本尚未发布，插件系统也远不如 VS Code 丰富。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 Rust（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
Atom 和 Tree-sitter 之后，Zed 想解决什么
Zed 的定位很明确：一个高性能、支持多人协作的代码编辑器。它由 Atom 和 Tree-sitter 的创造者开发，这本身就暗示了它的技术方向。Atom 是 Electron 应用，性能一直被人诟病，而 Tree-sitter 则是为了提供增量解析能力。Zed 用 Rust 重写，目标是把编辑器的响应速度提升到接近原生 IDE 的水平，同时把协作功能直接内置在编辑器核心中，而不是像 VS Code 那样依赖第三方插件。它面向的是那些对编辑器延迟敏感、需要多人实时编辑的开发者，尤其是使用 Rust、TypeScript 等语言的项目团队。
从仓库结构看 Zed 的架构与数据流
Zed 的仓库是一个大型 Rust 工作区，包含了编辑器核心、协作服务器、语言支持等多个 crate。从目录结构看，它分为 `crates`、`docs` 和 `script` 等部分，其中 `crates` 下每个子目录对应一个功能模块，比如编辑器、终端、语法高亮等。协作功能并非独立于编辑器之外，而是作为核心模块存在，这表明 Zed 的设计从一开始就把多人编辑当作一等公民。数据流上，Zed 使用 Tree-sitter 进行增量解析，这意味着编辑时只重新解析变化的部分，而不是整个文件，这是它性能优势的关键。协作方面，文档提到多人编辑功能，但具体的协议细节在 README 中并未展开，只能从仓库布局推测它可能使用了中央服务器来同步编辑状态。
安装与构建：从二进制到源码编译
Zed 的安装方式很直接。在 macOS、Linux 和 Windows 上，你可以从 zed.dev 下载预编译的二进制，或者通过各平台的包管理器安装。README 给出了具体的安装文档链接，但未列出命令。对于想从源码构建的开发者，仓库提供了 macOS、Linux 和 Windows 的构建指南，路径在 `docs/src/development/` 下。构建 Zed 需要 Rust 工具链，因为整个项目是 Rust 写的。一个值得注意的点是，Zed 的 CI 依赖 `cargo-about` 来检查第三方依赖的许可证，这暗示了构建过程对许可证合规有强制要求。如果你在贡献代码时添加了新依赖，必须确保其许可证符合 `script/licenses/zed-licenses.toml` 中 `accepted` 数组的定义，否则 CI 会失败。
许可证的双重性：GPL-3.0 与 Apache-2.0 的混合
Zed 的许可证不是单一的。README 明确指出，源代码主要采用 GPL-3.0-or-later，但某些标记为 Apache-2.0 的组件例外。这种双许可策略在开源项目中并不罕见，但需要谨慎对待。对于开发者来说，这意味着如果你修改了 Zed 的源码并分发，你的衍生作品也必须采用 GPL-3.0 或更高版本。Apache-2.0 的组件则允许更宽松的再分发。仓库还提供了 `cargo-about` 配置来自动管理依赖许可证，但 README 也提醒，如果对许可证合规有疑问，应该咨询律师。这实际上是一个明确的警告：Zed 的许可证并不适合所有场景，尤其是商业闭源项目。
协作功能的现实：多人编辑的承诺与限制
Zed 的宣传语是“多人代码编辑器”，但 README 并没有描述协作的具体实现方式。从仓库的讨论链接可以看出，Web 版本仍在跟踪中，这意味着协作功能目前主要依赖桌面客户端。多人编辑通常需要中央服务器来协调不同客户端的编辑操作，Zed 可能也采用了类似模型，但文档没有提供细节。一个明显的限制是，如果团队需要自建协作服务器，目前没有公开的部署指南。此外，协作功能对网络延迟敏感，如果团队成员分布在不同地区，体验可能不如本地编辑流畅。因此，Zed 的协作功能更适合小团队或同一网络环境下的开发者，而不是大规模分布式团队。
替代方案：VS Code 与 Neovim 的差异
Zed 的主要竞争对手是 VS Code 和 Neovim。VS Code 基于 Electron，性能开销较大，但插件生态极其丰富，支持远程开发和 Web 版。Zed 用 Rust 重写，启动和响应速度更快，但插件生态远不如 VS Code 成熟。Neovim 则是终端编辑器，性能出色，但需要用户学习 Vim 键位和配置。Zed 的多人协作是内置的，而 VS Code 需要安装 Live Share 插件，Neovim 则需要配合其他工具。Zed 的定位是提供一个开箱即用的高性能编辑器，但如果你依赖大量现有插件，或者需要 Web 端访问，VS Code 可能更适合。
维护与升级成本：活跃开发与许可证合规负担
从仓库的提交历史和版本发布看，Zed 的开发非常活跃，最近版本号到了 v1.18.0-pre，说明项目处于快速迭代阶段。这意味着你可以期待频繁的更新和新功能，但也带来了升级成本。每次升级可能需要重新编译或下载新二进制，而如果从源码构建，还需要处理依赖变化。许可证合规是另一个维护负担。Zed 使用 `cargo-about` 来强制检查依赖许可证，如果你修改了依赖，必须确保其许可证被 `accepted` 数组接受。这个机制保证了项目的合规性，但也要求贡献者熟悉许可证要求。对于企业用户来说，GPL-3.0 的传染性可能意味着需要法律审查，这增加了采用成本。
编辑结论
Zed 适合追求低延迟编辑体验、愿意接受 GPL-3.0-or-later 许可证约束的 Rust 或系统级开发者，尤其是那些重视多人实时协作的团队。不适合需要 Web 端支持或依赖大量成熟插件生态的用户，因为 Web 版本尚未发布，插件系统也远不如 VS Code 丰富。在采用前，应先确认你的项目能否合规使用 GPL 代码，并评估 Zed 的协作服务器是否满足团队的数据隐私要求。最终判断：Zed 是一个值得在 Linux 或 macOS 上尝试的高性能编辑器，但它的协作功能仍处于早期，且许可证可能成为商业项目的障碍。
社区笔记