Protobuf 终于拥有 LSP 支持
Protobuf has LSP support. You're welcome
Buf 正式宣布推出首个生产级 Protobuf LSP 服务器，彻底改变了 Protobuf 的开发体验。过去，Protobuf 缺乏像其他主流语言那样的现代 IDE 支持，如今通过 Buf CLI，开发者在 VSCode、IntelliJ 或 Neovim 中也能享受代码补全、跳转定义和语义高亮等智能功能。我们基于 protocompile 构建了全新的查询驱动前端，不仅比 protoc 更快，还能精准诊断重复修饰符等错误。这一更新让 Protobuf 不仅是明智的选择，更成为最容易上手的选择。
这是 Protobuf 开发的一次革命性突破：Protobuf 首次拥有了现代化的 IDE 支持，这一切都由 Buf CLI 驱动。
HN 评论区
148- jvolkman
> Protobuf now has modern IDE support for the first time
这篇帖子有点怪。大概 10 年前我在 Google 时开发了 IntelliJ 的 Protobuf 支持 [1]，它从 2021 年左右开始随 IntelliJ 默认发布。也许这不算“现代”？
- alecthomas
这帖子语气真是傲慢得离谱，Protobuf LSP 都出来好几年了：https://github.com/lasorda/protobuf-language-server
- lacoolj
从公司官方帖子里看到“不客气”（You're welcome）简直太好笑了。
- williamcotton
我看了看依赖项，发现它并没有使用现有的 Protobuf 解析器，这意味着他们是从头重写了解析器。也许是因为现有实现缺乏错误恢复能力？我现在没精力进一步检查了。
在实现 LSP 时，最好复用运行时（runtime）的解析器，但要正确做到这一点，就得把解析器本身实现为一个独立的库。更进一步，最好还能把语义分析也一起打包！
实现漂移（implementation drift）确实是个问题。
不过不管怎样，这是个很棒的项目，只是想把我的想法抛出来讨论一下！
- eterm
这里有很多唱反调的，但 Protobuf 的一个优势在于 proto 文件是手写友好的，因此为其提供 LSP 支持确实有用。
话虽如此，proto 本身会阻止或禁止你在 LSP 中常见的操作，比如重命名。
重命名字段是大忌 [编辑：这不对，见下文更正]，重新排序字段也是如此。
Proto 的一个核心理念是版本必须与之前的版本严格兼容。这本身对迁移工作带来了局限和挑战，但也鼓励了良好的兼容性实践，而这些实践在大多数生态系统中往往被忽视或一带而过。
不过我也承认，现在很容易把重构和版本兼容性检查都丢给 LLM，让它去处理。