技能介绍

它解决什么问题

当服务数量增长到几十个甚至上百个，.proto 文件会散落在各个仓库里：有的团队升级字段类型，有的团队悄悄删掉字段，直到某次部署才在集成测试中炸开。本技能针对的正是这种 schema 演进失控：跨团队协作时缺少统一的变更审查入口，breaking change 往往在生产环境才被发现；同时 buf lint 规则、buf config 工作区约定也没有人强制推行。

技能的工作方式

核心能力：

基于 buf CLI 的破坏性变更检测，在 CI 阶段拦截不兼容修改
集成 Confluent Schema Registry，管理不同版本的 subject 与兼容性策略
强制执行 buf lint 规则，统一团队的 proto 代码风格
通过 protoc-gen-go 与 protoc-gen-grpc-web 生成 gRPC 服务桩代码

关键步骤：

在仓库初始化阶段运行 buf config init，建立工作区配置
对每次 schema 变更执行 breaking 检查，输出不兼容字段的具体位置
将 schema 注册到 Schema Registry，按策略决定允许或拒绝发布
用 protoc 插件生成对应的 Go 类型与 gRPC-Web 客户端桩

适用边界与注意点

破坏性检查的效果依赖团队真正把 buf lint 和 breaking 检查接入 CI；工具装好不等于流程落地
目前流程描述以 buf 生态为主，未覆盖 Wire、protovalidate 等代码生成器的自动化路径
Schema Registry 集成指向 Confluent 风格协议；对接其他 registry 实现时需要确认兼容性参数
生成的桩代码仍需在业务仓库中随 schema 变更同步更新，registry 不会替你跑通编译

截图预览

使用场景

微服务数量达到几十个，每次合并前用 `buf` 跑 breaking 检查，定位不兼容字段位置，避免 schema 升级破坏下游调用方。
团队要把 Protobuf schema 注册到 Confluent Schema Registry，需要配置 subject 兼容性策略并执行发布与版本管理。
新 gRPC 服务需要基于 `.proto` 文件生成代码，通过 `protoc-gen-go` 和 `protoc-gen-grpc-web` 分别产出服务端类型与前端调用桩。
多团队共用一个 `buf` workspace，需要在 CI 中强制执行 `buf lint` 规则，统一 proto 命名风格与注释格式。