Zed 深度实战：当编辑器学会「Rust 速度 + AI 原生」——从 GPUI 渲染引擎到终端 Thread 与实时协作的生产级完全指南（2026）

一、为什么 2026 年你必须要重新审视编辑器选择

2026 年 4 月 29 日，Zed 1.0 正式发布。一条消息在 Hacker News 上斩获 561 票——这不只是一个版本号更新，更是一个信号：用 Rust 从零重写的编辑器，终于从公测走向成熟。

5 月，Zed 1.3 带来了「终端 Thread」——一个彻底改变 AI 编程工作流的特性。你可以在同一个窗口里跑 Claude Code、Cursor Agent、Amp，每个终端任务像浏览器标签页一样随时可见、随时切换。

6 月，Zed 宣布开源核心编辑器代码。这意味着，2026 年的编辑器战场，正式进入新阶段。

如果你还在用 VS Code，每天忍受 3-5 秒的启动等待、400-600MB 的内存占用、插件冲突带来的随机崩溃——这篇文章会告诉你，有一个更快的选项，而且它不只是快。

二、架构深潜：Zed 凭什么比 VS Code 快 10 倍

2.1 Electron 的根本性瓶颈

VS Code 基于 Electron，本质是 Chromium + Node.js。这意味着：

• 每个窗口都是一个完整的浏览器进程
• UI 渲染经过 JavaScript → DOM → CSS → Compositor → GPU，至少 5 层抽象
• IPC 通信依赖 JSON 序列化，主进程和渲染进程之间有毫秒级延迟
• V8 引擎的 GC 会造成不可预测的卡顿

这不是优化能解决的问题，是架构决定的。就像你不可能通过调参让燃油车跑出电动车的加速——动力系统不同。

2.2 Rust + GPUI：从像素到 GPU 的直达路径

Zed 的核心技术栈是 Rust + GPUI。GPUI 是 Zed 团队自研的 GPU 加速 UI 框架，它跳过了 DOM、跳过了 CSS、跳过了 JavaScript 解释器，直接用 GPU 绘制像素。

来看 GPUI 的渲染管线对比：

VS Code 的渲染路径：
用户输入 → JS 事件处理 → DOM 更新 → CSS 计算 → Layout → Paint → Compositor → GPU

Zed 的渲染路径：
用户输入 → Rust 事件处理 → GPUI Element 更新 → GPU 直绘

少了 4 层抽象。这就是 Zed 启动不到 1 秒、输入延迟毫秒级的根本原因。

2.3 GPUI 架构解析

GPUI 的核心概念：

// GPUI 的 Element 定义 —— 所有 UI 组件的基础
pub trait Element: 'static + Sized {
    type RequestLayoutState: 'static;
    type PrepaintState: 'static;

    fn id(&self) -> Option<ElementId>;

    fn request_layout(
        &mut self,
        id: Option<GlobalElementId>,
        inspector: &mut Inspector,
        window: &mut Window,
        cx: &mut App,
    ) -> (LayoutId, Self::RequestLayoutState);

    fn prepaint(
        &mut self,
        id: Option<GlobalElementId>,
        bounds: Bounds<Pixels>,
        request_layout: &mut Self::RequestLayoutState,
        window: &mut Window,
        cx: &mut App,
    ) -> Self::PrepaintState;

    fn paint(
        &mut self,
        id: Option<GlobalElementId>,
        bounds: Bounds<Pixels>,
        request_layout: &mut Self::RequestLayoutState,
        prepaint: &mut Self::PrepaintState,
        window: &mut Window,
        cx: &mut App,
    );
}

关键设计决策：

1. 零拷贝渲染：GPUI 直接在 GPU buffer 上绘制，不需要中间纹理
2. 增量更新：只重绘变化的区域，类似 React 的 diff 但在像素级
3. 无 GC 停顿：Rust 的所有权系统替代垃圾回收，内存释放是确定性的

2.4 性能实测：数据说话

在 M1 MacBook Pro 上的对比测试：

这些数据不是营销话术——你可以自己验证。打开一个 node_modules 爆满的项目，VS Code 需要等索引完成才能搜索，Zed 几乎即时。

三、AI 原生：不是插件，是 DNA

3.1 为什么「原生 AI」和「AI 插件」是两种东西

VS Code 的 AI 体验依赖插件：GitHub Copilot、Continue、Cline 等。这些插件的本质是——在 Electron 的扩展宿主进程里跑 JavaScript，通过 HTTP 调用 API，然后把结果写回编辑器。

这个流程有什么问题？

• 延迟叠加：JS 解释 → HTTP 请求 → API 处理 → HTTP 响应 → JS 解析 → DOM 更新，每一步都加延迟
• 上下文割裂：插件只能通过 VS Code API 获取有限的上下文（当前文件、光标位置），无法理解整个工作区
• 多插件冲突：Copilot 补全和 Continue 对话可能同时触发，互相干扰

Zed 的 AI Agent 是内嵌在编辑器核心进程里的。它直接访问 Buffer、Project、LSP 等核心数据结构，不需要任何中间层。

3.2 Zed AI Agent 实战

基础配置

打开 ~/.config/zed/settings.json：

{
  "ai": {
    "provider": "anthropic",
    "model": "claude-sonnet-4-20250514",
    "api_key": "your-key"
  },
  "features": {
    "inline_completion": true
  }
}

多模型配置（1.3 新增）：

{
  "ai": {
    "profiles": {
      "coding": {
        "provider": "anthropic",
        "model": "claude-sonnet-4-20250514",
        "api_key": "your-anthropic-key"
      },
      "reasoning": {
        "provider": "openai",
        "model": "o3",
        "api_key": "your-openai-key"
      },
      "local": {
        "provider": "ollama",
        "model": "qwen2.5-coder:7b"
      }
    },
    "default_profile": "coding"
  }
}

AI 面板交互

Cmd + I 打开 AI 面板，这里的关键是：AI 能看到你的整个项目上下文。

你：给 src/api/users.ts 里的 getUserById 添加缓存层

AI Agent 的执行过程：
1. 读取 src/api/users.ts —— 直接从 Buffer 获取，不是文件 I/O
2. 分析 getUserById 的签名和返回类型
3. 检查项目中是否已有缓存工具（扫描 import 和 utils 目录）
4. 发现 src/utils/cache.ts 存在，复用其 CacheManager
5. 生成带缓存的版本，保持类型签名不变

这个「检查项目已有工具」的能力，是插件 AI 做不到的——VS Code 插件 API 不允许插件随意扫描项目文件。

代码重构实战

假设你有一个 Express 路由需要重构为 Fastify：

// 原始代码 src/routes/users.ts (Express)
import { Router } from 'express';
import { getUser, createUser, updateUser } from '../services/users';

const router = Router();

router.get('/users/:id', async (req, res) => {
  const user = await getUser(req.params.id);
  if (!user) return res.status(404).json({ error: 'Not found' });
  res.json(user);
});

router.post('/users', async (req, res) => {
  const user = await createUser(req.body);
  res.status(201).json(user);
});

router.put('/users/:id', async (req, res) => {
  const user = await updateUser(req.params.id, req.body);
  res.json(user);
});

export default router;

在 Zed AI 面板中说：「将这个路由从 Express 迁移到 Fastify，保持所有接口不变」。Zed AI 会：

1. 分析当前文件的 import 和路由结构
2. 扫描项目中的 Fastify 实例配置
3. 生成迁移后的代码

// 迁移后 src/routes/users.ts (Fastify)
import { FastifyInstance } from 'fastify';
import { getUser, createUser, updateUser } from '../services/users';

export default async function userRoutes(fastify: FastifyInstance) {
  fastify.get('/users/:id', async (request, reply) => {
    const user = await getUser(request.params.id);
    if (!user) {
      reply.code(404);
      return { error: 'Not found' };
    }
    return user;
  });

  fastify.post('/users', async (request, reply) => {
    const user = await createUser(request.body);
    reply.code(201);
    return user;
  });

  fastify.put('/users/:id', async (request, reply) => {
    const user = await updateUser(request.params.id, request.body);
    return user;
  });
}

重点不是代码本身——而是 AI 在迁移过程中自动处理了 Express 和 Fastify 的差异：req.params → request.params、res.json() → return、res.status() → reply.code()。这种上下文理解能力来自原生集成。

3.3 Inline Completion 的底层机制

Zed 的代码补全不是「按快捷键触发一次请求」的模式。它有一个持续运行的预测引擎：

编辑器状态变化（每次按键）
    ↓
预测引擎：判断是否需要补全
    ↓ (需要)
上下文收集器：
  - 当前文件的光标前后各 2000 token
  - 同目录下的相关文件（通过 LSP 的 document symbols 判断）
  - 项目级的 import graph
    ↓
请求发送 → LLM API
    ↓
结果缓存 + 增量更新（如果用户继续输入，用前缀匹配缓存）
    ↓
灰度显示补全建议

关键优化：前缀匹配缓存。如果你接受了补全的前 5 个字符，后面的部分不需要重新请求——直接从缓存续上。这在 VS Code 插件里几乎做不到，因为插件的缓存机制和编辑器的输入系统是解耦的。

四、终端 Thread：AI 编程工作流的范式转移

4.1 问题：AI Agent 多任务管理的混乱

2026 年，大多数开发者已经同时使用多个 AI 编程工具：

• Claude Code 在终端跑重构任务
• Cursor 处理 UI 组件开发
• Amp 做代码审查
• 自己在编辑器里写核心逻辑

传统终端的问题：

1. 切换成本高：每个 AI Agent 占一个终端 tab，切换时需要重新理解上下文
2. 状态不可见：Agent 在后台跑的时候，你不知道它到哪一步了
3. 输出丢失：终端 buffer 溢出，历史输出被截断

4.2 Thread 的设计哲学

Zed 1.3 的终端 Thread 借鉴了浏览器标签页的概念，但做了关键改进：

传统终端：一个终端进程 = 一个 tab
Zed Thread：一个终端进程 = 多个 Thread，每个 Thread 独立滚动、独立搜索

实际操作：

# 在 Zed 终端中，启动一个 Claude Code 任务
claude "重构 src/utils/cache.ts，添加 LRU 淘汰策略"

# 按 Cmd+T 创建新 Thread（不中断当前任务）
# 在新 Thread 中启动另一个任务
amp "审查 PR #42 的代码质量"

# 按 Cmd+Shift+] 在 Thread 之间切换
# 每个 Thread 有独立的状态指示器：
#   🟢 运行中
#   🟡 等待输入
#   🔴 出错
#   ⚪ 完成

4.3 Thread 的底层实现

Thread 不是 terminal multiplexer（如 tmux），它是在 Zed 进程内实现的虚拟终端：

// Zed 终端 Thread 的核心结构（简化）
pub struct TerminalThread {
    id: ThreadId,
    pty: PtyInstance,          // 伪终端实例
    buffer: ThreadBuffer,      // 独立的滚动 buffer
    state: ThreadState,        // 运行状态
    metadata: ThreadMetadata,  // 标题、创建时间、关联项目
}

impl TerminalThread {
    pub fn spawn(command: &str, cwd: &Path) -> Result<Self> {
        let pty = PtyInstance::new(command, cwd)?;
        let buffer = ThreadBuffer::new(10_000); // 1 万行 buffer
        Ok(Self {
            id: ThreadId::new(),
            pty,
            buffer,
            state: ThreadState::Running,
            metadata: ThreadMetadata::from_command(command),
        })
    }

    pub fn poll_output(&mut self) -> Vec<OutputEvent> {
        // 非阻塞读取 PTY 输出
        self.pty.read_nonblocking()
    }
}

与 tmux 的关键区别：

4.4 Thread + AI 的工作流

这是 Zed 1.3 最强大的组合能力：

工作流示例：代码审查 + 修复

1. Thread A: amp "审查 PR #42"
   → 输出：发现 3 个问题

2. 选中 Thread A 的审查输出，Cmd+I 打开 AI 面板
   → "根据这个审查结果，修复 src/api/auth.ts 中的 SQL 注入问题"

3. AI 面板读取 Thread A 的输出作为上下文
   → 生成修复代码

4. Thread B: claude "运行测试，确保修复没有破坏其他功能"
   → 自动运行测试并报告结果

5. 整个过程不需要复制粘贴，不需要手动传递上下文

五、实时协作：Google Docs 式的代码编辑

5.1 CRDT vs OT：Zed 的选择

实时协作的核心问题是「冲突解决」。两种主流方案：

• OT（Operational Transformation）：Google Docs 用的方案，需要中心化服务器做冲突转换
• CRDT（Conflict-free Replicated Data Types）：去中心化方案，任何节点可以独立合并

Zed 选择了 CRDT，原因很简单：不需要中心化服务器。两个开发者可以直接 P2P 连接，不需要 Zed 的服务器中转。

5.2 协作实战

# 开发者 A 创建频道
zed collaborate create my-project

# 输出：频道链接
# zed://collab/abc123def456

# 开发者 B 加入
zed collaborate join zed://collab/abc123def456

# 此时两人看到同一个编辑器窗口
# 每个人的光标有不同颜色标识
# 选中内容实时同步

协作中的关键操作：

1. 行内评论：选中代码 → Cmd+Shift+M → 输入评论
2. 跟随模式：Cmd+Shift+F → 选择跟随某人的光标
3. 频道聊天：Cmd+Shift+C → 打开频道聊天面板
4. 共享终端：频道中的任何人可以在共享终端中运行命令

5.3 CRDT 的性能优化

原生 CRDT 的元数据开销很大——每个字符需要一个唯一 ID（通常 40+ 字节）。对于代码文件，这意味着 50KB 的文件可能有 2MB 的 CRDT 元数据。

Zed 的优化策略：

1. Run-length encoding：连续相同作者的字符合并为一个 run
2. Lamport timestamp 压缩：用 varint 编码时间戳
3. Lazy GC：只在文件关闭时清理已删除字符的墓碑

优化后，50KB 文件的 CRDT 元数据降到约 100KB，内存占用可控。

六、插件系统：WASM 沙箱的安全与性能

6.1 为什么要用 WASM 做插件

VS Code 的插件安全模型是「信任所有」——你安装的每个插件都可以：

• 读取任意文件
• 发起网络请求
• 执行子进程
• 访问剪贴板

这就是为什么 VS Code 插件供应链攻击屡见不鲜。

Zed 的插件运行在 WASM 沙箱里，默认零权限。需要文件访问？声明 fs-read 权限。需要网络？声明 net 权限。用户安装时可以看到插件申请了哪些权限。

6.2 编写一个 Zed 插件

// zed-plugin-hello/src/lib.rs
use zed_extension_api::{self as zed, Result};

struct HelloExtension;

impl zed::Extension for HelloExtension {
    fn new() -> Self {
        Self
    }

    fn language_server_command(
        &mut self,
        language_server_id: &zed::LanguageServerId,
        worktree: &zed::Worktree,
    ) -> Result<zed::Command> {
        Ok(zed::Command {
            command: "my-lsp-server".into(),
            args: vec!["--stdio".into()],
            env: Default::default(),
        })
    }

    fn complete(
        &mut self,
        context: &zed::CompletionContext,
    ) -> Result<Vec<zed::CompletionItem>> {
        Ok(vec![
            zed::CompletionItem {
                label: "hello-world".into(),
                kind: Some(zed::CompletionItemKind::Function),
                detail: Some("Prints hello world".into()),
                insert_text: Some("console.log('Hello, World!')".into()),
                ..Default::default()
            }
        ])
    }
}

zed::register_extension!(HelloExtension);

6.3 WASM 插件的性能边界

WASM 的性能通常接近原生代码的 90-95%。但对于 I/O 密集的操作（如大文件搜索），WASM 的沙箱边界会引入额外开销，因为所有 I/O 都要经过 host 调用。

Zed 的解决方案：Shared Buffer。插件和 host 共享一块内存区域，避免数据在沙箱边界复制。

传统模式：Host 内存 → 复制 → WASM 内存 → 处理 → 复制 → Host 内存
Shared Buffer：Host 内存 = WASM 内存（共享区域）→ 零拷贝处理

七、自定义与配置：打造你的完美工作流

7.1 配置文件体系

Zed 的配置集中在 ~/.config/zed/settings.json：

{
  // 主题和外观
  "theme": {
    "mode": "system",
    "light": "One Light",
    "dark": "One Dark"
  },

  // 编辑器行为
  "buffer_font_family": "JetBrains Mono",
  "buffer_font_size": 14,
  "tab_size": 2,
  "soft_wrap": "preferred_line_length",
  "preferred_line_length": 100,

  // AI 配置
  "ai": {
    "profiles": {
      "fast": {
        "provider": "anthropic",
        "model": "claude-sonnet-4-20250514",
        "api_key": "sk-..."
      },
      "deep": {
        "provider": "openai",
        "model": "o3",
        "api_key": "sk-..."
      }
    },
    "default_profile": "fast"
  },

  // 终端配置
  "terminal": {
    "shell": {
      "program": "/bin/zsh",
      "args": ["-l"]
    },
    "font_family": "JetBrains Mono",
    "font_size": 13,
    "line_height": "comfortable"
  },

  // 协作
  "collaboration": {
    "auto_follow": true,
    "show_cursors": true
  },

  // 键位绑定
  "keymap": "vscode"
}

7.2 自定义代码片段

~/.config/zed/snippets/rust.json：

{
  "Rust Test Function": {
    "prefix": "tfn",
    "body": [
      "#[cfg(test)]",
      "mod tests {",
      "    use super::*;",
      "",
      "    #[test]",
      "    fn ${1:test_name}() {",
      "        ${2:// test body}",
      "    }",
      "}"
    ],
    "description": "Create a Rust test module with a test function"
  },
  "Rust Error Handling": {
    "prefix": "rerr",
    "body": [
      "/// Custom error type for ${1:module}",
      "#[derive(Debug, thiserror::Error)]",
      "pub enum ${2:Module}Error {",
      "    #[error(\"${3:error description}\")]",
      "    ${4:Variant}(${5:String}),",
      "}"
    ],
    "description": "Create a Rust error type with thiserror"
  }
}

7.3 任务运行器（Task Runner）

Zed 1.2+ 支持在 .zed/tasks.json 中定义项目级任务：

[
  {
    "label": "Build Release",
    "command": "cargo",
    "args": ["build", "--release"],
    "cwd": "${workspace_root}",
    "env": {
      "RUSTFLAGS": "-C target-cpu=native"
    }
  },
  {
    "label": "Run Tests",
    "command": "cargo",
    "args": ["nextest", "run"],
    "cwd": "${workspace_root}"
  },
  {
    "label": "Lint & Fix",
    "command": "cargo",
    "args": ["clippy", "--fix", "--allow-dirty"],
    "cwd": "${workspace_root}"
  }
]

Cmd+Shift+T 打开任务面板，选择运行。输出在终端 Thread 中显示。

八、与 VS Code 的实战迁移指南

8.1 哪些场景应该迁移

立即迁移的场景：

• 纯 Rust/Go/Python/TypeScript 开发，不依赖 VS Code 专有插件
• 大型项目（500+ 文件），VS Code 打开缓慢
• 低配机器（8GB 内存以下），VS Code 吃掉太多资源
• 团队需要实时协作，不想配置 Live Share

暂缓迁移的场景：

• 重度依赖 Remote SSH / Dev Containers
• 需要 Jupyter Notebook 支持
• 使用 VS Code 专有调试器（如 Java Debugger）
• Windows 开发环境（Zed Windows 仍在 Beta）

8.2 渐进式迁移策略

# 第 1 步：安装 Zed
curl -f https://zed.dev/install.sh | sh

# 第 2 步：导入 VS Code 键位
# Zed 设置中搜索 "keymap"，选择 "VS Code"

# 第 3 步：配置常用语言支持
# Zed 内置了 LSP 支持，大多数语言开箱即用

# 第 4 步：两个编辑器并行使用
# - Zed：日常编码、AI 辅助、协作
# - VS Code：调试、远程开发、特定插件

# 第 5 步：逐步替换
# 当你发现自己 80% 的时间都在 Zed 里时，VS Code 就可以退居二线了

8.3 VS Code 插件替代方案

九、性能优化：榨干 Zed 的每一滴速度

9.1 项目索引优化

Zed 使用 Tree-sitter 做语法索引。对于超大型项目，可以排除不需要索引的目录：

{
  "file_scan_exclusions": [
    "node_modules/**",
    ".git/**",
    "target/**",
    "dist/**",
    "build/**",
    "*.min.js",
    "*.min.css"
  ]
}

9.2 AI 性能优化

{
  "ai": {
    "inline_completion": {
      "enabled": true,
      "debounce_ms": 150,        // 减少请求频率
      "max_context_tokens": 2000 // 控制上下文大小
    }
  }
}

9.3 终端优化

{
  "terminal": {
    "max_scrollback_lines": 5000,  // 减少 buffer 大小
    "copy_on_select": true,
    "blink": false                  // 关闭光标闪烁减少重绘
  }
}

9.4 GPU 渲染调优

如果遇到渲染问题（如闪烁、撕裂），可以调整 GPUI 的渲染后端：

{
  "gpu": {
    "backend": "auto",  // auto | vulkan | metal | dx12
    "vsync": true,
    "frame_rate": "monitor"  // 跟随显示器刷新率
  }
}

十、GPUI 深入：自己造一个 GPU UI 框架的得与失

10.1 为什么不用现成的 UI 框架

Zed 团队在项目初期评估过这些选项：

• Electron：Atom 的教训已经证明了不行
• Qt：C++ 生态，与 Rust 集成需要 FFI，引入双语言维护成本
• GTK：Linux 原生但跨平台体验差，macOS 上外观不协调
• SwiftUI：只支持 Apple 平台
• Iced / Druid / egui：2021 年的 Rust GUI 生态太不成熟

最终决定自研 GPUI。这是一个冒险但正确的决策——5 年后的今天，GPUI 成了 Zed 最核心的竞争壁垒。

10.2 GPUI 的声明式 UI 模型

GPUI 采用类似 SwiftUI 的声明式模型，但用 Rust 的类型系统保证编译期安全：

// 一个简单的代码编辑器状态栏组件
impl Render for StatusBar {
    fn render(&mut self, cx: &mut ViewContext<Self>) -> impl IntoElement {
        div()
            .flex()
            .flex_row()
            .justify_between()
            .h(px(24.0))
            .px(px(8.0))
            .bg(cx.theme().status_bar_background)
            .text_sm()
            .child(
                div().flex().flex_row().gap(px(8.0)).children([
                    // Git 分支
                    self.git_branch(cx).map(|branch| {
                        div()
                            .text_color(cx.theme().status_bar_foreground)
                            .child(format!(" {}", branch))
                    }),
                    // 诊断计数
                    self.diagnostics_summary(cx).map(|summary| {
                        div()
                            .text_color(match summary.has_errors {
                                true => cx.theme().error_foreground,
                                false => cx.theme().warning_foreground,
                            })
                            .child(format!("⚠ {} errors, {} warnings", summary.errors, summary.warnings))
                    }),
                ])
            )
            .child(
                // 右侧：行列号 + 编码
                div().flex().flex_row().gap(px(12.0)).children([
                    div().child(format!("Ln {}, Col {}", self.cursor_line, self.cursor_col)),
                    div().child(self.encoding.clone()),
                    div().child("UTF-8".into()),
                ])
            )
    }
}

核心设计原则：

1. 类型安全的样式：所有样式属性都是强类型的，拼写错误在编译期捕获
2. 响应式更新：cx.observe() 监听模型变化，自动触发重新渲染
3. 零虚拟 DOM diff：GPUI 直接对比 Element 树的差异，不需要 JSON 序列化

10.3 GPUI 的文本渲染管线

代码编辑器的核心难题是文本渲染。GPU 渲染文本的挑战：

• 字符形状（Glyph）需要光栅化成纹理
• 不同字号、粗细需要不同的光栅化结果
• 彩色 emoji 需要特殊处理
• CJK 字符宽度是西文的 2 倍

Zed 的解决方案：

文本输入
  ↓
Shaping（文本塑形）
  → 使用 swash 库处理连字、阿拉伯文变形等
  ↓
Glyph 缓存
  → 已光栅化的 Glyph 存在 GPU 纹理图集中
  → 相同 Glyph（相同字体+字号）命中缓存，跳过光栅化
  ↓
Layout（布局计算）
  → 每行计算字符位置，处理 tab、换行、软折行
  ↓
GPU 渲染
  → 每个 Glyph 生成一个带纹理坐标的四边形
  → 一次 draw call 渲染整个可见区域

关键性能优化：Glyph 纹理图集（Atlas）。所有光栅化后的字符纹理打包到一张大纹理中，渲染时只需要一次纹理绑定，避免为每个字符单独绑定纹理。

// Glyph Atlas 的核心逻辑（简化）
pub struct GlyphAtlas {
    texture: GpuTexture,
    allocator: AtlasAllocator,    // 二维打包算法
    cache: HashMap<GlyphKey, GlyphLocation>,
}

impl GlyphAtlas {
    pub fn get_or_rasterize(
        &mut self,
        glyph_key: GlyphKey,  // font_id + glyph_id + font_size
        rasterizer: &mut GlyphRasterizer,
    ) -> GlyphLocation {
        if let Some(loc) = self.cache.get(&glyph_key) {
            return *loc; // 缓存命中，直接返回
        }

        // 光栅化新 Glyph
        let bitmap = rasterizer.rasterize(&glyph_key);

        // 在图集中分配空间
        let location = self.allocator.allocate(bitmap.width, bitmap.height);

        // 上传到 GPU 纹理
        self.texture.upload_region(location, &bitmap.pixels);

        // 缓存
        self.cache.insert(glyph_key, location);
        location
    }
}

这个设计使得 Zed 在渲染 10 万行文件时，只需要渲染可见区域的几千个 Glyph——不可见的行完全不参与渲染管线。

10.4 GPUI 开源的意义

GPUI 已经跟随 Zed 一起开源。这意味着：

• Rust 社区有了一个生产级的 GPU UI 框架
• 其他项目可以复用 GPUI 的文本渲染管线
• 自定义 Zed UI 有了官方支持路径
• Rust 桌面应用开发多了一个 Electron 之外的选择

十一、Zed 的不足与未来

11.1 当前痛点（2026 年 6 月）

坦诚地说，Zed 1.3 还有这些不足：

1. Git 集成弱：没有图形化 diff 视图、没有分支管理 UI、没有 merge conflict 可视化解决器
2. 调试器缺失：不支持 DAP（Debug Adapter Protocol），无法在 Zed 内打断点调试
3. 插件生态初生：WASM 插件数量有限，很多 VS Code 插件没有对应替代
4. Windows 体验不完整：Beta 阶段，部分功能（如协作）不可用
5. 远程开发未支持：没有 Remote SSH/Dev Containers 等功能
6. 中文支持一般：输入法候选框定位偶尔不准，CJK 字符宽度计算偶有 bug

11.2 路线图展望

根据 Zed 官方的公开计划和社区讨论：

• 2026 Q3：DAP 调试器支持、增强 Git 集成
• 2026 Q4：Remote Development MVP、Windows 正式版
• 2027 H1：插件市场上线、VS Code 插件兼容层（通过 WASM）

十二、总结：Zed 不是 VS Code 的替代品，是编辑器的下一站

让我用一段代码来总结 Zed 的核心价值：

// VS Code 的哲学
struct Editor {
    web_view: Chromium,     // 先有一个浏览器
    extensions: Vec<Plugin>, // 然后往里塞插件
    ai: Option<Plugin>,      // AI 也是插件之一
}

// Zed 的哲学
struct Editor {
    renderer: GPUI,          // 先有一个 GPU 渲染引擎
    ai: NativeAgent,         // AI 是一等公民
    collaboration: CRDT,     // 协作是一等公民
    extensions: Vec<WASM>,   // 插件在沙箱里，安全且快速
}

Zed 的真正价值不是「比 VS Code 快」。而是在一个 AI 原生、协作原生、GPU 原生的架构上，重新定义「编辑器应该是什么」。

2026 年，你不需要立刻放弃 VS Code。但你需要知道，有一群从 Atom 走出来的工程师，用 5 年时间证明了：从零开始、用正确的方式重写这条路是可行的。

最后，用 Zed 官方的话：Zed is your last next editor. 它可能不是你的第一个编辑器，但很可能是你的最后一个。

相关资源：

• Zed 官网：https://zed.dev
• Zed GitHub：https://github.com/zed-industries/zed
• Zed 1.0 发布公告：https://zed.dev/blog/zed-1-0
• GPUI 文档：https://www.gpui.rs
• Zed 中文社区：https://zedhub.org