Rust Glancer 是什么？

Rust Glancer 是 2026 年 8 月 19 日正式公开的低内存 Rust LSP 语言服务器，由开发者 popzxc 历时 4 个月开发。它的核心卖点和 rust-analyzer 完全不同：不把整个工作区的分析数据常驻内存，而是"冻结"后卸载到文件系统，从而把空闲内存占用压到 100MB 以内——在大型项目上比 rust-analyzer 低一到两个数量级。

发布仅三天，它就获得了 rust-analyzer 原作者 matklad 的公开背书（原话是"incredibly cool"），Hacker News 帖子拿到 120+ 分，Reddit r/rust 社区 230+ 赞。对于长期被 rust-analyzer 吃掉几个 GB 甚至 13GB 内存的 Rust 开发者来说，这是 2026 年最值得关注的编辑器基础设施新项目。

先把最关键的事实说清楚：

• 内存目标 <100MB：中等规模项目空闲内存 100MB 以内，超大项目约 200-300MB；
• 重启零等待：索引结果存在磁盘上，重启编辑器后无需重新索引，几乎是"秒开"；
• 取舍明确：查询响应比 rust-analyzer 慢（补全在几百毫秒级），只在保存文件时重新索引，proc macros 暂不支持；
• 主编辑器是 VS Code：官方扩展已上架 VS Code Marketplace，其他支持 LSP 的编辑器理论上可用；
• 开源免费：Apache-2.0 协议，GitHub 仓库 rust-glancer/rust-glancer。

一句话总结：如果你的电脑内存常年被 rust-analyzer 挤爆，或者你在一台 8GB 内存的老机器上写 Rust，Rust Glancer 值得立刻试；如果你重度依赖 proc macros 和极致补全速度，先观望。本文把它是什么、为什么省内存、和 rust-analyzer 怎么选、怎么装一次讲清。

Rust Glancer 核心信息速览

它解决什么问题：rust-analyzer 的内存痛点

要用好 Rust Glancer，得先理解它针对的痛点有多普遍。在 Reddit r/rust 和 rust-analyzer 的 GitHub issues 里，"内存"是常年霸榜的抱怨主题：

• rust-analyzer 官方仓库存在多个高热度内存 issue（如 #11325 Why does Rust Analyzer use so much RAM and CPU?、#20917 Excessive RAM usage、#13954 High memory usage）；
• Rust 官方论坛有用户反馈 rust-analyzer 在大工作区吃掉 13GB 内存；
• Reddit 上《rust-analyzer is eating my memory》《rust-analyzer is absolutely murdering my laptop》这类帖子隔三差五就会出现。

为什么 rust-analyzer 内存这么高？项目作者在发布博文里给出了三条原因：

1. Rust 工作区信息量天然巨大：几千个函数、结构体、trait 以及它们之间的关系都要索引，每个符号都占内存——这是 Rust 语言本身的复杂度决定的；
2. salsa 增量数据库常驻内存：rust-analyzer 用 salsa 做惰性增量计算数据库，算过的数据全部留在 RAM 里，方便增量复用，但代价是内存只增不减；
3. rowan 语法树全量驻留：语法树结构支持部分失效重解析，性能好，但整棵树都在内存里。

结果就是：工作区越大、依赖越多，rust-analyzer 的内存占用越高。在 16GB 内存的开发机上，开一个 IDE + rust-analyzer + 浏览器 + Docker，内存基本见底。这也是为什么"低配机写 Rust"一直是社区的老大难问题。

工作原理：冻结工作区，数据落盘

Rust Glancer 的思路和 rust-analyzer 相反，可以概括为"用空间换内存、用全量换增量"：

• rust-analyzer：所有数据常驻内存，靠 salsa 增量按需重算。查询快，但内存占用持续保持在高位；
• Rust Glancer：索引用"急切"（eager）方式一次性全量做完，做完后把结果冻结（frozen workspace）并卸载到文件系统。查询时只把当前需要的那一小部分加载回内存。

这个设计带来两个直接收益：

空闲内存极低。索引完成后，内存里只留运行必需的少量数据。作者实测整个演示视频期间内存保持在 100MB 以下；在 8GB 内存的 MacBook Pro M1（2020 款）上体验"相当不错"——这台机器正是很多开发者被 rust-analyzer 折磨的典型配置。

重启即恢复。因为索引在磁盘上，只要你没改代码，重新打开编辑器时已索引的工作区几乎立即可用。而 rust-analyzer 每次重启都要重新跑一遍索引，大项目动辄等十几秒到几十秒。

作者在 Hacker News 上补充了一个容易被误解的点：Rust Glancer 在索引期间可能比 rust-analyzer 占用更多内存（因为它是非惰性的全量索引），但索引结束把数据落盘后，内存会掉下来。而 rust-analyzer 是"一直在高位"。另外，查询时按需加载的数据量也更小——项目可能有 1000+ 个依赖，但你当前查询往往只关心正在打开的这个文件。

Rust Glancer vs rust-analyzer：怎么选

这是大家最关心的问题。两者不是替代关系那么简单，而是不同架构路线的取舍：

作者公布的索引时间基准（发布博文数据）：

可以看到冷启动索引并不吃亏，甚至略快；真正的差异在重启场景（Rust Glancer 免二次索引）和稳态内存（低一到两个数量级）。

选择建议：

• 选 Rust Glancer：8-16GB 内存的机器、经常同时开多个项目、在意编辑器启动速度、能接受补全稍慢、项目不依赖 proc macros；
• 选 rust-analyzer：32GB+ 大内存机器、依赖 proc macros 重度项目（serde、tauri 等生态）、对补全实时性敏感、需要完整类型推断覆盖。

两者也可以共存：它们理论上能同时运行不冲突（作者实测过），但同时跑两个 LSP 意义不大，官方文档建议装 Rust Glancer 时把 rust-analyzer 扩展禁用。

社区反响：rust-analyzer 作者亲自背书

Rust Glancer 的热度不完全是"新项目流量"，它的含金量来自行业头部人物的认可：

• matklad（rust-analyzer 原作者）：2026 年 8 月 21 日发表博文《Rust Glancer》，称其"低两个数量级的内存占用，非常酷，去看看吧"。他还在文中给出了技术层面的公允分析：rowan 的增量解析服务于"你正在编辑的那个文件"这 1% 的场景，而 99% 的场景是"6666 个你永远不会看的依赖只需要浅层分析"——Rust Glancer 恰好是为这 99% 设计的。他还预测性地提出了改进方向（函数体处理惰性化）和 proc macros 的解法（类似 Sorbet 的 shim 方案，不真正执行宏而是注入空实现）。这篇博文本身也是 Hacker News 帖子的来源；
• Hacker News：matklad 提交的帖子《Rust Glancer: Rust LSP using 100x less RAM》7 小时内冲到 122 分、32 条讨论，作者 popzxc 本人在评论区逐条答疑；
• Reddit r/rust：作者发帖《Rust Glancer: a memory-efficient Rust language server》，一天内 239 赞、39 条讨论；
• Lobste.rs：同步讨论，标签里赫然写着 "vibecoding"——不少人已经在把它当作 AI 辅助编程工作流的标配（AI Agent 高频改代码时，LSP 内存和重启速度直接影响迭代效率，matklad 在博文中也专门讨论了 agent 编辑代码时 rust-analyzer 的 inlay hints 错位问题）。

值得一提的是，matklad 在博文中坦承 rust-analyzer 的架构包袱（"半画的马"），并介绍了 IntelliJ 的 PSI 多后端思想——打开的文件用完整语法树、其余项目用磁盘上的紧凑 Stub Tree。Rust Glancer 的出现，某种程度上验证了这条路线在 Rust 生态的可行性。

限制与已知问题：装之前必须知道

作者非常坦诚地在文档里列出了现状，这些限制决定了它现在适合谁：

1. 不是完整的 LSP：项目只有 4 个月历史，"缺少很多功能、有已知 bug"，作者自己也说"对某些人这可能是 deal breaker"；
2. proc macros 不支持：依赖 serde derive、sqlx、tauri 这类宏的重度项目体验会明显缺功能（宏展开的代码看不到分析结果）；
3. 只在保存时索引：你正在打字的未保存内容，分析精度低于已保存文件。官方为此用了一些"hack"让编辑体验可接受，但原理上做不到 rust-analyzer 那种实时精确；
4. 部分场景类型推断不工作：大部分"正常"Rust 语法已支持（含完整的类型推断管线和基于 chalk 的 trait solver），但边角场景仍有缺失；
5. 查询速度整体慢于 rust-analyzer：虽然"人类感知上可接受"，但对补全延迟极敏感的用户需要适应。

作者的表态是：他正在用 Rust Glancer 开发 Rust Glancer（自举），并且"以它目前的形式已经够用"。这句话比任何营销文案都有说服力。

谁该现在就用？

适合立刻上手的场景

• 低内存机器：8GB MacBook、老款 ThinkPad、云主机、树莓派级设备上写 Rust；
• 多项目并行开发者：同时开 3-5 个工作区，rust-analyzer 每个实例都要吃几百 MB 到几 GB；
• 频繁重启/切换编辑器的人：磁盘索引 + 秒级恢复，工作流更顺滑；
• AI Agent 工作流重度用户：agent 高频批量改代码、频繁触发重索引时，低内存和快速恢复是实打实的效率；
• 喜欢尝鲜、愿意给新项目提 issue 的开发者：项目 Apache-2.0 开源，正处在最欢迎反馈的阶段。

不适合的场景

• proc macros 重度项目：宏展开分析缺失是硬伤；
• 对补全毫秒级延迟敏感的用户：查询性能有折损；
• 需要"开箱即用全功能"的团队生产环境：功能尚不完整，建议先在个人分支试用。

一句话行动清单

在 VS Code 里装上 Rust Glancer 扩展（记得先 rustup component add rust-src，再禁用 rust-analyzer），拿你手上那个最吃内存的 Rust 项目跑一天，用任务管理器看内存对比——具体步骤见站内教程《Rust Glancer 怎么安装使用：VS Code 配置教程与常见问题排错》。

相关阅读

• 站内教程：Rust Glancer 怎么安装使用：VS Code 配置教程与常见问题排错——rust-src 组件、扩展安装、禁用 rust-analyzer 与排错全步骤
• 官方网站：https://rust-glancer.github.io/
• 发布博文《Hello, world!》：https://rust-glancer.github.io/blog/hello-world/
• GitHub 仓库：https://github.com/rust-glancer/rust-glancer
• matklad 的评测博文：https://matklad.github.io/2026/08/21/rust-glancer.html
• Hacker News 讨论：https://news.ycombinator.com/item?id=49393052
• 站内指南：AI 编程工具怎么选：AI IDE、代码助手与 Agent 的区别
• 站内指南：Vibe Coding 入门指南：零基础第一周该干什么

本文信息截至 2026 年 8 月 22 日，基于 Rust Glancer 官网、官方文档、发布博文、matklad 博文及 Hacker News、Reddit 社区公开讨论整理。项目处于快速迭代期，功能与限制可能随时变化，请以官方文档为准。