留意 Zed 这个代码编辑器也有一段时间了，作为一个使用编译型开发语言 Rust 开发的产品，性能及内存占用的优势自然是非常明显的，并且这款产品的一个亮点就是集成了 AI (其实现在主流的代码编辑器都有)。尤其是 Zed 的创始人是 Atom 的作者，已经有丰富的同类产品的开发经验，做出来的 Zed 非常值得期待。
只可惜，初次尝试 Zed 时，发现功能并不完善，连最基本的编译调试功能都没有，所以始终没有从 VSCode 切换到 Zed。
直到今年（2025年）6月，官方终于发布了 Debugger 功能，算是补上了 Zed 的一大短板。
VSCode VS Zed
从 Zed 官方文档说明可知，Zed 的编译调试配置文件 debug.json 的格式与 VSCode 的 launch.json 的格式非常相似，甚至可以直接复制过来用。但是尝试在 Zed 中直接运行已有的 Golang 项目时，却遇到了问题。后来发现 Zed 与 VSCode 的编译调试表面相似，但还是有些细节上的差异的。
我以一个实际的 Go 项目为例，项目目录结构如下：
/test
--/src
----go.mod
----go.sum
--/bin
----config
项目的实际源码放在 /test/src 目录下面，但为了方面管理整个项目组，使用代码编辑器打开的是 test 目录。这样就会涉及到编译与运行的执行路径的问题，特别是在项目代码里面有相对路径的情况下就会报错，例如：读取 /bin 目录的 config 文件。
首先是在 VSCode 中编译运行没有问题的 launch.json 配置如下：
{
"name": "test",
"type": "go",
"request": "launch",
"mode": "auto",
"program": "bin",
"cwd": "bin"
}
使用以上配置，在 VSCode 中直接按快捷键 F5 运行，代码顺利编译运行，并且编译完成即时运行的程序也可以顺利读取到 /bin/config 文件。
再来看看 Zed 的 debug.json 配置文件的内容：
{
"label": "test_zed",
"adapter": "Delve",
"request": "launch",
"program": "${ZED_WORKTREE_ROOT}/bin",
"cwd": "${ZED_WORKTREE_ROOT}/bin",
"mode": "debug"
}
配置内容大同小异，但可惜的是编译报错：
Build Error: go build -o /Users/test/bin/__debug_bin3210007602 -gcflags all=-N -l /Users/test/bin/__debug
go: cannot find main module, but found .git/config in /Users/test
to create a module there, run:
cd .. && go mod init (exit status 1)
把以上的编译命令行放到终端执行，如果是在 /test 目录下执行就会报这个错，但在 /test/src 目录下执行就可以正常编译。
这样对比一下 VSCode 与 Zed 相似配置的情况下，VSCode 似乎比 Zed 多了一个智能定位源码目录的功能（也有一个说法是 VSCode 的 Go 插件实现的这个功能），VSCode 虽然打开的是 /test 目录但准确地识别出应该在 /test/src 中执行编译命令，但 Zed 就没有做到这一点。而且因为 Zed 是内置的 Go 语言支持，所以目前也没有相关的插件。
当然，以上的问题可以通过在 "cwd" 中配置到 src 目录，但这样编译完成后程序自动运行时的启动目录就不是 /bin 目录，无法使用相对路径读取 /bin/config 文件。
Zed Golang 编译调试配置
意识到了这一点后，修改 Zed 的 debug.json 配置来满足编译调试需求也不难。思路就是不要让 Zed 全自动生成完整的编译指令，而是通过人工干扰及命令拼接的方式实现这一需求。
先来看看能够让以上工程目录结构的 Golang 代码在 Zed 中编译运行调试的 debug.json 配置：
{
"label": "test_zed",
"adapter": "Delve",
"request": "launch",
"program": "$ZED_WORKTREE_ROOT/bin/your_out_filename",
"cwd": "${ZED_WORKTREE_ROOT}/bin",
"mode": "exec",
"build": {
"cwd": "${ZED_WORKTREE_ROOT}/src",
"command": "go",
"args": ["build", "-o", "${ZED_WORKTREE_ROOT}/bin/your_out_filename", "."]
}
}
上面的配置就是把 mode 由 debug 改成了 exec ，也就是说 Zed 只负责执行这部分，然后通过 build 指令段配合 args 实现编译命令的拼接，在编译命令里指定执行编译的目录，这样就能够完美地避开了 Zed 无法同时在 A 目录执行编译然后直接在 B 目录运行程序的问题。
其它选项
只是一个执行程序时的相对路径问题，也可以在项目代码里面直接使用绝对路径（推荐）来解决，这样能够使程序更加健壮，这样就可以直接使用第一个 Zed 的 debug.json 配置就可以编译运行了.
会从 VSCode 切换到 Zed 吗
我个人来说还是比较喜欢 Zed 的，强大的性能及较少的内存占用非常吸引我，我放弃 JetBrains 家的产品也是因为他们家的产品内存占用太高了。并不是说他们产品不好，也不是说我缺这点内存，只能说我喜欢功能能满足需求的同时更轻量化、而且一个窗口就能满足多种开发语言的产品。所以我从 JetBrains 家的产品切换到了 VSCode。
得益于 VSCode 庞大且成熟的插件生态，VSCode 给我的工作带来了极大的便利，在了解 Zed 之前我是没有动过切换到 VSCode 之外的代码编辑器的念头。
但试用了 Zed 之后，我开始动摇了，但目前对于我个人来说，Zed 还是不如 VSCode 便捷的，所以应该在一段时间内两者交替使用吧。