Buf宣布推出首个生产级Protobuf语言服务器协议（LSP）支持，为Protobuf提供现代IDE功能，包括跳转定义、代码补全、查找引用和语义高亮，这被视为Protobuf开发的重要突破。

Buf 自豪地宣布推出首个功能完备、生产级的 Protobuf LSP 服务器。语言服务器协议（LSP）是集成语言支持到 IDE 或文本编辑器的标准 API，可提供跳转到定义、代码补全、查找引用和语义感知语法高亮等功能。此前，Protobuf 缺乏其他主流编程语言所拥有的 LSP 支持，而这一突破由 Buf CLI 驱动，为 Protobuf 开发带来了现代 IDE 支持。

Buf 认为 Protobuf 是最佳模式语言，拥有成熟的库和工具生态系统。为了让 Protobuf 成为既明智又简单的选择，Buf 发布了 LSP 服务器，作为完善 Protobuf 生态系统的工具家族的一部分，包括 Protobuf-ES、Protovalidate、ConnectRPC 和 Buf Schema Registry。

安装 Buf LSP 的方法：在 VSCode 中，安装 Buf 扩展即可自动使用已安装的 Buf CLI（包含 LSP 服务器）；在 Neovim 中，需安装 Buf CLI 并配置 Neovim 使用它作为 LSP 服务器，例如添加 lspconfig.buf_ls.setup {} 到 .nvimrc，或通过 init.lua 配置 vim.lsp.config 和 vim.lsp.enable。其他编辑器需了解 LSP 集成方式，并运行 buf lsp serve 命令启动服务器。

Buf 维护的 Protobuf 编译器前端 protocompile 比 protoc 更快更灵活，甚至被 Google 用于部分代码库。为构建 Buf LSP，Buf 开发了全新的查询驱动前端，支持增量编译和更优的诊断，例如正确诊断重复的 repeated 修饰符。新设计的 AST 和中间表示能精确诊断错误，易于实现新语言特性，且内存高效，可处理大型 Buf 模块。

Buf 承诺持续改进 Buf LSP，计划添加更多功能：自动修复 import、与 buf.yaml 更紧密集成、自定义选项的代码补全和引用查找、自动建议字段/枚举编号、以及专门的 Protovalidate 支持（包括 CEL 片段的语法高亮）。Buf 将不断推动 Protobuf 的边界，实现模式驱动开发。如需帮助组织强制执行数据标准，可联系 Buf；若对开发优秀工具感兴趣，可查看招聘页面。

以下是对评论内容的总结，涵盖主要观点和论据，并保持不同观点的平衡性：

1. 对 Protobuf 的质疑与批评 - LLM 时代必要性降低：有评论认为，在 LLM 时代，Protobuf 的注册表和代码生成 SDK 变得不那么必要，甚至开始质疑其优势（评论1）。关键引用："Buf's offering of protobuf registries and codegen SDKs for microservices seems less necessary in the LLM era." / "I'm starting to question many of protobuf's advantages." - 性能与可靠性问题：有用户指出，在 Python 中使用 JSON 替代 gRPC 后，客户端变得更快、更可靠，并提供了代码示例（评论2）。关键引用："If you patch clients to google services in Python to use json instead of grpc they get faster and more reliable. A lot faster." / "It is a nuisance to manage and distribute the definitions, adds a build step... is slower than almost every alternative." - 实现质量差：同一评论批评 Protobuf 的实现代码质量低劣，像“醉酒的实习生写的”（评论2）。关键引用："It's like a team of interns wrote it while drunk. It is a complete spaghetti mess."

2. 对 Protobuf 的辩护与认可 - 版本兼容性优势：有评论认为 Protobuf 的核心优势在于强制版本兼容，鼓励良好实践，尽管迁移有挑战（评论4）。关键引用："A core idea of proto is that versions are strictly compatible with with previous versions. This itself has limitations and challenges for migrations, but encourages good practice." - Buf 的改进作用：有用户称赞 Buf 在修复 Protobuf 使其“勉强可用”方面做出了贡献，对遗留项目是“天赐之物”（评论6）。关键引用："Buf does great work at fixing Protobuf to the point of being just barely usable. A godsend if you're stuck with Protobuf/gRPC on a legacy project."

3. 对 Buf 公司及 LSP 的批评 - 傲慢态度：多位评论者批评 Buf 的“You're welcome”措辞显得傲慢或令人不适（评论7、11）。关键引用："'You're welcome' is absolutely hilarious to read from a company post." / "'You're welcome.' is such a smug verbal tic." - LSP 并非首创：有评论指出 Protobuf LSP 早已存在，Buf 并非第一个（评论9、12）。关键引用："What an oddly arrogant post, there's been a Protobuf LSP available for years." / "I built IntelliJ protobuf support... like 10 years ago."

4. 其他观点 - 替代方案：有评论推荐了游戏领域的替代语言“schema”（评论3）。关键引用："if you are working in the video game space where struct versioning is not needed, there is an alternative language called 'schema'." - 实现问题：有评论指出 Buf 的 LSP 可能未复用现有 Protobuf 解析器，存在实现漂移风险（评论5）。关键引用："I looked at the dependencies and noticed that it wasn’t using an existing Protobuf parser which means they reimplemented the parser from scratch." - 语言差异：有评论认为 Protobuf 在 Java 中表现良好，但在 JS 中不佳（评论10）。关键引用："It worked great in Java, but not so well in JS, especially with Kafka."

总结：评论呈现两极分化。一方面，部分用户质疑 Protobuf 在 LLM 时代的必要性、性能、实现质量及 Buf 的傲慢态度；另一方面，也有用户认可其版本兼容性优势及 Buf 的改进作用。此外，关于 LSP 的首创性和实现细节也存在争议。