必须统一proto仓库并模块化引用，通过独立git仓库集中管理共享proto文件，用go.mod replace指令精准指向版本，隔离go包名与输出路径避免代码污染，并在wire中按需注入依赖以实现变更隔离。
当你在多个微服务间复用同一份.proto定义（如通用错误码、基础数据结构或跨域实体）时，必须解决路径冲突、生成代码污染、版本不一致三大问题——直接拷贝proto文件会导致后续维护成本翻倍，而硬链接或子模块又容易在CI/CD中触发权限或路径解析失败。
统一Proto仓库与模块化引用
将所有共享proto文件集中存放在独立Git仓库（如github.com/your-org/api-common），目录结构按语义分层：
api-common/
├── base/
│ ├── status.proto
│ └── pagination.proto
├── user/
│ └── user_base.proto
└── shared.proto
在各服务的go.mod中添加replace指令，指向本地克隆路径或Git commit hash：
replace github.com/your-org/api-common => ../api-common
【replace必须写在go.mod最顶部，且不能与其他replace混行，否则wire gen会因import路径解析失败而静默跳过生成】
执行kratos proto client时，工具会自动识别replace并从指定路径读取.proto，无需修改--proto_path参数。
避免生成代码污染：隔离Go包名与输出路径
方法一：在shared.proto顶部显式声明go_package，且与服务自身包名严格区分
syntax = "proto3";
package common.v1;
option go_package = "github.com/your-org/api-common/base;basepb";
方法二：生成时强制指定输出目录，不落入默认api/子树
kratos proto client --grpc=false --http=false \
--out=./internal/pb/common \
../api-common/base/status.proto
这一步必须手动执行，kratos new默认不会处理外部proto路径。
注意：若同时生成HTTP和gRPC代码，需确保--out路径下无同名.pb.go文件残留，否则protoc会追加而非覆盖，导致编译报duplicate symbol错误。
服务级依赖注入控制：Wire中按需加载
第一步：在internal/data中定义接口，只引用所需pb类型
type UserRepo interface {
GetByID(ctx context.Context, id string) (*basepb.Status, error)
}
第二步：wire.go中仅注入实际用到的pb包，禁止_ blank import整个common模块
func init() {
wire.Build(
data.NewUserRepo,
// 不要写：basepb.RegisterStatusService
)
}
第三步：在service层构造函数参数中，只接收biz层定义的接口，而非pb结构体本身
func NewUserService(repo data.UserRepo) *UserService {
return &UserService{repo: repo}
}
这样当status.proto变更时，只有data.UserRepo实现和调用它的test文件需要调整，biz和service层完全无感知。
