protobuf 三十六版：跨语言数据交换的编译器与运行时，到底该怎么选
Google 提出的语言中立、平台中立的结构化数据序列化机制，由 protoc 编译器与多种编程语言的运行时组合而成。
秒懂
- 它是什么？
- Protocol Buffers 是 Google 的语言中立序列化机制，本篇文章从 v36.0 的仓库现状出发，拆解它的编译器、运行时、构建方式与版本支持策略，并指出它不适合哪些场景。
- 适合谁用？
- protobuf 适合需要跨语言、跨平台稳定交换结构化数据的团队，尤其是已经在用 Bazel 8 或 Google 生态的工程。它不适合数据量极大、要求极低延迟的实时系统，也不适合只想做临时 JSON 传输的小项目。
- 能商用吗？
- 请先确认。这个仓库使用的许可证不在我们自动归类的范围内，商用前请阅读仓库里的 LICENSE 文件。
- 还在维护吗？
- 在维护。仓库在最近一天内有新的提交。
- 用什么语言写的？
- 主要是 C++（依据 GitHub 的语言统计）。
以上回答依据项目的 GitHub 数据（最近同步于 2026年9月15日）和我们的分析，不构成法律意见。
开源项目深度解析
一个格式，两个组件，三层问题
Protocol Buffers 解决的问题很具体：不同语言写的服务之间，怎么交换结构化数据而不必为每种语言写一套序列化代码。它把数据结构写进 .proto 文件，再用编译器生成各语言的类。这个仓库同时承载两样东西：protoc 编译器，以及 C++、Java、Python 等语言的运行时库。两者必须配套，版本错位就会出问题。README 明确说，主分支的构建会偶尔被源码不兼容的改动破坏，所以普通用户应该用发布版本，而不是追 main。
protoc 是入口，运行时是落点
数据流是单向的：你写 .proto 文件，protoc 读取它，生成目标语言的代码，然后你的程序链接对应语言的运行时库。编译器本身用 C++ 写成，预编译二进制只对发布版本提供。如果你需要 HEAD 版本，或者要改 protobuf 源码，就得自己从源码构建。这个设计把编译器与运行时的版本绑定在一起，意味着升级 protoc 时，所有语言的运行时都要同步升级。仓库里每个语言目录都有独立的安装说明，这是实际操作的起点。
从源码构建：Bazel 8 与 WORKSPACE 的岔路
README 给出了两条 Bazel 路径。新项目应该用 Bzlmod，在 MODULE.bazel 里写 bazel_dep(name = "protobuf", version = <VERSION>)，还可以用 repo_name 覆盖仓库名以兼容旧 WORKSPACE。老项目继续用 WORKSPACE，但 30.x 之后多了 rules_java 和 rules_python 的加载语句。这暴露了一个事实：protobuf 的构建依赖链条在变长，从 30.x 开始，你不仅要加载 protobuf_deps，还要手动处理 java 和 python 的规则。如果你不用 Bazel，就只能走预编译二进制或各语言的包管理器。这个选择直接影响你升级的难度。
语言支持矩阵：官方与分叉的边界
README 列出的语言支持并不统一。C++、Java、Python、Objective-C、C#、Ruby、PHP 的运行时在这个仓库里维护。Go 在 protocolbuffers/protobuf-go，Dart 在 dart-lang/protobuf，JavaScript 在 protocolbuffers/protobuf-javascript。这意味着 Go 或 Dart 的运行时版本节奏与主仓库不同步，你升级 protoc 后，可能需要单独去别的仓库找匹配的运行时。这个分叉不是问题，但你要意识到，跨语言兼容性验证不能只看这个仓库的 release。
版本支持策略：一个必须提前读的文档
README 指向 protobuf.dev/version-support/，要求用户了解各语言库的支持时间窗口。这暗示了 protobuf 的维护成本：不同语言的运行时可能在不同时间停止支持旧版本，你的项目如果长期不升级，可能被某个语言的运行时抛弃。仓库本身不承诺主分支稳定，README 直接警告说主分支的构建会被破坏。因此，生产项目必须锁定发布版本，并且要定期查看支持策略，而不是等出问题再处理。
预编译二进制：最省事，但有边界
非 C++ 用户可以直接从 GitHub release 下载 protoc-$VERSION-$PLATFORM.zip，里面包含 protoc 二进制和一组标准 .proto 文件。这个包只对发布版本提供，而且只覆盖常见平台。如果你用 ARM 架构的旧服务器，或者需要交叉编译，可能找不到现成包，就得回退到源码构建。这个路径适合大多数应用开发者，但不适合需要定制 protoc 插件或修改编译器行为的人。
真正的替代方案：JSON 与 Thrift 的差异
如果你只需要在少数语言间交换轻量数据，JSON 是更简单的替代，它不需要编译器，也不需要运行时版本匹配，但代价是类型约束弱、序列化体积大。Apache Thrift 是另一个选择，它同样用 IDL 定义结构，但更强调 RPC 框架，而 protobuf 本身只负责序列化，RPC 是 gRPC 的事。Thrift 的编译器与运行时同样有版本匹配问题，但它的语言支持范围更窄。如果你的核心需求是跨语言强类型数据交换，protobuf 的生态更成熟；如果只是临时传输，JSON 的维护成本更低。
v36 时代的判断：稳定优先，追新需谨慎
v36.0 在 2026 年 8 月发布，距离 v36.0-rc2 只有两周多，说明发布节奏在收紧。但 README 对主分支的警告依然有效：源码不兼容改动会随时出现。我的判断是，protobuf 的价值在于它的长期稳定性，而不是新功能速度。如果你的团队已经用 Bazel 8，并且愿意跟随官方支持策略定期升级，那么它值得采用。如果你只是想要一个快速序列化方案，或者你的语言不在官方列表里，那么你应该先解决运行时匹配问题，再考虑引入。
编辑结论
protobuf 适合需要跨语言、跨平台稳定交换结构化数据的团队，尤其是已经在用 Bazel 8 或 Google 生态的工程。它不适合数据量极大、要求极低延迟的实时系统，也不适合只想做临时 JSON 传输的小项目。采用前需要确认三件事：你的目标语言运行时是否在官方支持列表内，protoc 版本与运行时版本是否匹配，以及你是否愿意承担主分支的构建不稳定风险。如果这些条件都满足，protobuf 是可行的选择，但它不是万能胶，序列化格式的演进会长期影响你的兼容性维护。
社区笔记