Rust Glancer：把 Rust LSP 内存压到 100MB 以下的替代实现（0822）
Rust Glancer：把 Rust LSP 内存压到 100MB 以下的替代实现
Rust 圈昨天炸出一件新鲜事：一个叫 Rust Glancer 的项目，宣称自己是「专注于低内存的 Rust LSP 替代实现」，在 HN 上冲到 360+ 分，rust-analyzer 的作者 matklad 亲自写博客站台。
先给结论：它不是要取代 rust-analyzer，而是给「机器不够好、或愿意牺牲部分完整度换内存」的人多一个选择。项目自己说得也很清醒——不装。
核心数据：内存目标与索引速度
项目作者在博客开头就摆明定位，原句：
an alternative Rust LSP implementation that is built with a focus on low memory usage.
两个主打特性，第一个就是内存：
- 极低内存占用（合理项目 target <100mb）
- 重启后立即恢复索引，不用重新建索引
作者给了一张实测表，Rust Glancer 对比 rust-analyzer 的索引时间：
| 机器 | 索引类型 | Rust Glancer | rust-analyzer |
|---|---|---|---|
| MacBook Pro M4 Max, 36GB (2025) | 基础索引 | 5 秒 | 6 秒 |
| MacBook Pro M4 Max, 36GB (2025) | 全量索引 | 8 秒 | 13 秒 |
| MacBook Pro M1, 8GB (2020) | 基础索引 | 6 秒 | 7 秒 |
| MacBook Pro M1, 8GB (2020) | 全量索引 | 9 秒 | 14 秒 |
作者还补了一句：
throughout this video, the used RAM remained under 100mb
演示全程内存都没超过 100MB。这对 8GB 老机器的意义，用过 rust-analyzer 的人都懂。
为什么 rust-analyzer 那么吃内存
matklad 在站台文章里直接点破了根因，措辞相当不客气：
rust-analyzer uses rowan for syntax tree representation... Yeah, rowan is garbage :P
翻译一下这段吐槽：rowan 的树形表示会带来严重的内存碎片，导致从 OS 拿的 RAM 远高于「实际使用」的 RAM。rust-analyzer 选它是为了更快，也确实做到了——但这套架构天然跟内存绑定，很难把部分数据挪到内存之外。
Rust Glancer 的思路反着来：不做增量 LSP，改用「冻结的分析结果 + 保存时失效」。核心好处是：
- 分析结果可以落盘，需要时才加载进内存
- 保存的分析结果可复用，重启编辑器不用重新索引
代价作者也明说：冻结的分析天生比惰性增量慢，得靠「输入时只做浅层分析、复用上次完整索引」来补救。所以新写的 import、struct、trait 要保存后才进索引。
别把它当 rust-analyzer 杀手
这是我最欣赏这个项目的一点——它不吹牛。作者原话：
it's highly unlikely that Rust Glancer will ever become "just like rust-analyzer, but better".
定位很清楚：要完整度和逐键精度，继续用 rust-analyzer；机器弱、愿意拿完整度换内存，才轮到 Glancer。
几条现实约束，装之前先掂量：
- 它还不是完整 LSP，缺不少功能、有已知 bug
- 已有完整索引管线 + 类型推断 + trait solver（chalk），大部分常规语法和 goto definition、hover、inlay hints、completions 都能用
- build scripts / proc macros 大概率不会支持——作者明确说这类需要跑不可信代码的场景不在计划内
matklad 补了一个技术判断：rust-analyzer 曾测出 30% 的二进制体积花在 JSON 解析上，proc macro 展开慢是因为要跑真实代码。Rust Glancer 选择绕开这条路，代价就是放弃这部分能力。
对 Agent 工作流的意外优化
一个有意思的细节：作者观察到 rust-analyzer 在 Agent 编辑代码时，inlay hints 会错位。Rust Glancer 专门为此做了优化——自定义 file watcher，且对「编辑器外变更」降低优先级，Agent 的批量改动不会触发频繁重建索引。
对现在越来越多人用 Agent 改 Rust 代码来说，这是个实打实的加分项。
你今天可以做的事
- 机器内存紧张、或开了好几个 IDE 工作区的人，直接装 VS Code 扩展试：
rust-glancer.rust-glancer - 别急着删 rust-analyzer——两者可以共存，弱机/大依赖树项目用 Glancer，重重构用 rust-analyzer
- 关注它后续的 proc macro 方案：作者提了个「不执行真实代码」的怪招，如果真成了会是 LSP 圈的大新闻
FAQ
Q：Rust Glancer 是 rust-analyzer 的分叉吗？ 不是。它是独立实现，4 个月从「smart ctags for Rust」一路长成真 LSP。作者给 rustc、clippy、rust-analyzer 都贡献过代码，但这是全新项目，不是 fork。
Q：它能替代 rust-analyzer 日常用吗？ 取决于你的项目。普通语法、goto definition、hover、inlay hints、completions 都可用，但缺功能、有 bug，且 build scripts / proc macros 大概率不支持。作者自己已经拿它当日常主力用了约 1.5 个月。
Q：那个「100x less RAM」的说法准确吗？ HN 标题写的是「100x less RAM」，matklad 的说法是「two orders of magnitude less RAM」。项目自己更保守，用的是「target <100mb」这个可验证目标，并给了演示视频全程 <100MB 的实测。具体倍数因项目而异，别把这个 marketing 数字当真，看实测表更靠谱。
参考来源：