写 Rust 的人对 rust-analyzer 大多是又爱又恨。爱的那面不用多说，它把 Rust 的编辑器体验从“高级记事本”拉到了和主流语言相当的水平；恨的那面也很集中，就两件事——内存和首次索引。一个中等规模的 workspace 索引完，常驻几个 G 是常态；如果同时开着两个窗口、workspace 里塞了好几个 crate，十几 G 也不稀奇。一旦开启 build script 和过程宏，每次打开编辑器风扇都要转上一阵。
Rust Glancer 就是冲着这两件事来的。作者写了四个月，八月十九号发出第一篇公开说明，随后在技术社区里被顶到了很靠前的位置。它的自我定位相当克制：不是 rust-analyzer 2.0，只求做到“90% 完整”，够日常干活就行；换来的是常驻内存目标控制在 100MB 以内，以及编辑器重启后不需要重新索引。
省内存这件事听起来像调参数，实际是架构选择的结果。作者把 rust-analyzer 吃内存的原因拆成三条：第一条是 Rust workspace 本身信息量就大——几千个函数、结构体、trait 以及它们之间的关系，想支持“查找所有引用”就绕不开，这条谁来写都得认；第二条是 rust-analyzer 用 salsa 做增量查询数据库，惰性计算的思路很漂亮，但数据天然和内存绑死，很难把一部分挪到别处；第三条是语法树用了 rowan，树形结构带来部分失效的能力，代价是内存碎片严重——向操作系统要的内存，明显多于真正在用的。
于是 Rust Glancer 干脆反着来：不做增量。整个 workspace 索引一次，结果冻结下来写进文件系统，保存文件时才失效；查询时需要什么，就在查询期间从磁盘把对应那块加载进来，用完就释放。这个决定一次性解决了两个问题——分析结果既然已经在磁盘上，重启编辑器时它当然还在，所以重启不需要重新索引；同时内存里只需要放当前查询用得到的部分，峰值自然下来了。
代价也很直接：从磁盘反序列化肯定比从内存读慢。为了让打字时不卡，Rust Glancer 在敲键盘期间不做完整分析，只对当前函数体做一次浅层分析，其余部分复用上一次完整索引的结果。补全因此够快，但也带来一个必须适应的习惯——新写的内容在保存之前是“看不见”的。比如刚敲下 struct FooBar;，紧接着写 impl Foo，补全里不会出现 FooBar；刚加的 use std::collections::HashMap;，在保存前写 fn foo(h: HashMa 也补不出来。作者的说法是养成“加了结构体、trait、import 或函数就顺手存一下”的肌肉记忆，用一阵子就不觉得别扭了。这话有点像自我安慰，但对习惯了随手 Ctrl+S 的人来说确实成本不高。
性能数字方面，作者给了两台机器的对比。在 2025 款 M4 Max、36GB 内存上，Rust Glancer 基础索引（引擎可用）5 秒、完整索引 8 秒，rust-analyzer 分别是 6 秒和 13 秒；在 2020 款 M1、8GB 内存的老 MacBook Pro 上，Rust Glancer 是 6 秒和 9 秒，rust-analyzer 是 7 秒和 14 秒。差距不算悬殊，但考虑到内存量级的差异，这个成绩已经说明冻结分析的路子跑得通。真正的意义在后一台机器上——8GB 的旧笔记本原本根本跑不动 Rust 开发环境，现在能跑了。
四个月做出一个带类型推导和 trait 求解器的 LSP，听起来不太可能。作者自己也承认，最初根本没打算写 LSP，只想做个“聪明一点的 ctags”。结果是复用 rust-analyzer 的语法库把 item 降级成内部表示，顺手做了模块结构和定义映射，然后忍不住加了简单的类型传播。有了类型就想要 inlay hint，有了 inlay hint 又想支持更多写法。压垮“只做 ctags”这个幻想的是下面这段代码：
fn mul_by_two(vals: &[u8]) -> Vec<u8> {
vals.iter().copied().map(|v| v * 2).collect()
}
代码本身平平无奇，但要正确处理它，需要切片类型、闭包与 Fn trait、trait 求解、关联类型投影，外加一堆 nightly 特性——作者原本想躲开 nightly，后来才反应过来标准库本身就是靠 nightly 特性堆起来的。最后他放弃了手写的 trait 匹配启发式，直接集成了 chalk，反而比自己那套层层叠叠的 hack 简单。
还有一处是针对当下工作方式的调整。现在很多人让编码代理在编辑器外面大批量改文件，rust-analyzer 在这种情况下 inlay hint 容易错位。Rust Glancer 早期也一样，后来靠自己实现的文件监视器解决了，并且把编辑器外的变更设成低优先级，避免代理一改动就触发密集重新索引。这算是个挺实际的细节。
想试的话，先确认 rustup component add rust-src 装过了，这是硬性前提；然后从 VS Code 扩展市场装 rust-glancer，或者克隆仓库跑 just package-vsix 自己打包 vsix 再本地安装——作者自己更推荐后者，理由是编辑器扩展近年来是供应链攻击的重灾区。装完记得把 rust-analyzer 关掉，两个一起跑不冲突但没意义。遇到索引乱掉、LSP 不响应之类的情况，先用命令面板执行 Rust Glancer: Reindex workspace，不行就重启服务，再不行就关掉编辑器删掉 target/rust_glancer 重来。作者刻意没做复杂的自动恢复，理由是“LSP 本来就不该崩，崩了就得吵闹一点，这样才能被修好”。
值得一提的是，作者在 README 和公开说明里都主动写了一段 LLM 使用声明：这个项目重度使用了大模型，但不是 vibe coding，每个 PR 他都逐一过目，git 历史里那些上万行的 diff 之间隔着好几天。他的请求是——如果觉得代码是垃圾，请说“他写的垃圾”，而不是“AI 写的垃圾”。在眼下这种氛围里，一个独立开发者要提前把这段话写在最前面，本身也挺说明问题。
我的判断是，Rust Glancer 短期内不会、作者也不打算让它取代 rust-analyzer。补全的完整性、按键级的准确度，这些仍然是 rust-analyzer 的主场。但对两类人它现在就有用：手上是内存吃紧的旧机器，或者习惯同时开好几个 workspace 的。功能上它还缺 code action、缺自动导入、缺过程宏支持，版本号也才 0.1.1，属于要有心理准备的阶段。不过一个能在 8GB 老本上正常干活的 Rust 语言服务器，这件事本身就值得留意。
项目地址： https://github.com/rust-glancer/rust-glancer
发表于 前天 23:46
|
查看: 19|
回复: 0
