写Rust久了，你一定熟悉这个场景：项目稍微大一点，rust-analyzer 的内存占用就开始按 GB 算，风扇狂转，补全开始卡顿。
Rust 开发者默认用的语言服务器（LSP）几乎都是 rust-analyzer，VS Code、Neovim、Emacs 的补全、跳转定义全靠它，没有替代品。这不怪机器：Rust 工程要索引的信息量本来就大；而 rust-analyzer 的 salsa 增量数据库为了"改完代码立刻响应"把分析数据钉在内存里，rowan 语法树的树状结构还会造成内存碎片。RustGlancer官方博客知乎问题"你们觉不觉得 rust 开发中最鸡肋的东西是 rust-analyzer？"下，高赞回答满是无奈：代码量大肯定卡，能做的只有关掉 check on save、微调参数，或者换台机器。知乎
8 月 19 日，一个叫 RustGlancer 的项目发布了，作者 popzxc 写了四个月。RustGlancer官方博客他是写了约七年 Rust 的职业开发者，给 rustc 和 rust-analyzer 提交过代码，动机直白：他习惯同时开两个 IDE，rust-analyzer 一度吃掉他 16GB 内存。
他给出两个承诺：
内存极低。合理规模的项目，目标常驻内存小于 100MB；
重启不用重新索引。索引结果持久化到磁盘，重启编辑器后直接加载可用。
这两条正好打在 rust-analyzer 最痛的两个点上：吃内存、每次重启都要等索引。微博作者附上自测数据：36GB 的 M4 Max 上，完整索引 8 秒对 13 秒；8GB 的老 MacBook M1 上，9 秒对 14 秒。索引只是略快，真正的差距在内存——官方博客的进程监控截图里，两个 rust-glancer 进程的内存加起来不到 100MB。RustGlancer官方博客
取舍不是免费的
怎么做到的？Glancer 的思路是不做增量分析。
rust-analyzer 把所有分析状态放在内存里，换你改一行代码就立刻给出推理结果；Glancer 则把分析结果冻结、按保存失效、落盘存储、按需加载。微博代价同样明确：你拿到的不是"这一秒"，而是"上次保存时"的分析。打字时它只对当前函数体做浅层分析、复用上一份完整索引，所以新写的 import 和类型，在保存之前不会进索引。RustGlancer官方博客作者说得很直白：它永远不会变成"更好版的 rust-analyzer"，重视完整性和逐键准确性的项目，rust-analyzer 仍是默认选择；Glancer 面向弱机器，以及愿意牺牲一点实时性换内存的人。
不过它的完成度超出预期：完整的类型推理和 Chalk trait 求解、声明式宏展开、跳转定义、悬停提示、内联提示、补全都能用，甚至对 AI 编程场景做了优化——编辑器外的 agent 改代码不会触发高频重建索引。RustGlancer官方博客
谁该换，谁别换
建议试的：小内存（16GB 及以下）跑大型 workspace 的人；同时开多个 Rust 项目、内存一开就爆的人；频繁重启编辑器、不想每次等索引的人。
不建议急着换的：工作节奏容不下过期结果的人；重度依赖 build script 和 proc macro 的项目——Glancer 明确不打算支持执行它们，这是目前最大的能力缺口。RustGlancer官方博客
换之前，先冷静三件事
第一，项目很年轻：仓库 4 月 29 日才建，目前约 400 星，VS Code 扩展 8 月 20 日才发到 v0.1.1，所有数据都是作者自测，还没有第三方验证。VS Code插件市场第二，"小于 100MB"是带适用条件的目标值，大项目请做好超出的心理预期。RustGlancer官方博客第三，试用成本几乎为零：LSP 只是编辑器后端服务，rust-glancer 扩展可以和 rust-analyzer 并存，先拿一个非核心项目跑一跑，手感合适再扩大范围。
接下来值得盯的信号：社区的第三方实测数据，以及官方博客路线图里的 code actions 和 proc macro 支持。RustGlancer官方博客
