Rust Glancer 用轻量架构挑战语言服务器内存膨胀
据 rust-analyzer 主要作者之一 Aleksey Kladov 对 Rust Glancer 的评论，这个实验性 Rust 语言服务器在一些项目中只使用 rust-analyzer 约百分之一的内存。它通过缩小分析范围，换取更轻的常驻成本。
据 rust-analyzer 主要作者之一 Aleksey Kladov 对 Rust Glancer 的评论，这个实验性 Rust 语言服务器在一些项目中只使用 rust-analyzer 约百分之一的内存。它通过缩小分析范围，换取更轻的常驻成本。
一句话结论：Rust Glancer 不是“更好的 rust-analyzer”，而是在追问一个更有价值的问题：编辑器真的需要把几千个依赖都按正在编辑的源码那样完整分析吗？
Rust 工具链的困难并不只是代码量大。trait 关系、宏展开、build script、类型推断和“查找所有引用”都会迫使语言服务器保存大量中间状态。rust-analyzer 为增量编辑和重构维护一致的代码快照，这带来强大能力，也带来数 GB 级内存占用的真实抱怨。
Rust Glancer 选择少做一些事。Kladov 认为，当前打开并频繁修改的文件确实需要完整语法树和增量分析；项目里尚未打开的文件可以只索引外部可见信息；绝大多数只读依赖更适合直接读取 rustc 编译生成的 .rmeta 元数据。这个思路与 IntelliJ 对源码、stub tree 和编译产物使用不同后端的做法相近。
真正棘手的是透明切换：当用户跳进依赖源码，工具既要从紧凑元数据切换到完整分析，又不能让跳转、补全和引用结果突然变化。过程宏也是分界线。运行过程宏意味着执行真实代码，会生成大量用户看不见的源码；Rust Glancer 若不支持它，可以很轻，但功能覆盖必然与 rust-analyzer 不同。
所以“低两个数量级内存”不能脱离功能集比较。更合理的解读是，语言工具可能需要冷热分层，而不是所有代码一视同仁。Agent 同时打开多个 worktree、多个编辑会话之后，这个问题会更突出：单个 LSP 尚能接受的 3 GB，乘上十个并行任务就会变成基础设施成本。
关键事实
- 项目：Rust Glancer，一款实验性 Rust LSP。
- 设计重点：降低常驻内存，而非完整复刻 rust-analyzer 功能。
- 核心建议：当前文件完整分析，未打开源码用紧凑索引，依赖优先读取
.rmeta。 - 已知取舍：过程宏、build script 和深度重构等能力更难覆盖。
OC 判断
Rust Glancer 最重要的产出可能不是替代品，而是把“分析精度是否应该分层”重新放到桌面上。Agent 时代的 IDE 会同时管理更多仓库副本，工具链若仍假定自己独占一台电脑，内存问题只会更明显。
为什么重要
- 对 Rust 开发者：低内存设备和大型 monorepo 可能获得新的工具选择。
- 对工具作者：编译器元数据可以成为 IDE 冷数据层，而不只是构建产物。
- 对 Agent 平台：每个任务节省几 GB 内存，会直接提高并行密度。
评论
围绕这篇文章补充信息、提出问题或分享观察。