go mod init 后不同框架对 go.sum 处理差异大，因框架是否自带依赖注入、代码生成或运行时插件机制：go-zero 的 goctl 生成 RPC 代码时自动引入 zrpc 及其传递依赖，触发 go.sum 频繁更新；而手写 grpc-go 项目仅随显式 go get 变动，go.sum 稳定。
go mod init 之后，为什么不同框架对 go.sum 处理方式差异很大
因为框架是否自带依赖注入、代码生成或运行时插件机制，直接决定 go.sum 是否会被频繁重写。比如 go-zero 在 goctl 生成 RPC 代码时会自动引入 github.com/zeromicro/go-zero 及其 transitive deps，而纯 grpc-go + 手写 .proto 的项目，go.sum 只随你显式 go get 变动。
常见错误现象：在 go-zero 项目里执行 go mod tidy 后，go.sum 突然多出几十行，CI 构建失败；但用 grpc-go 自建服务却几乎不变。
-
go-zero默认启用goctl模板内嵌的依赖版本锁定（如zrpc、redisclient），每次生成都会触发go mod download，建议把goctl版本固定在go.mod注释里，例如：// goctl version: v1.7.5 - 用
grpc-go时，go.sum只反映你import的实际包，但要注意google.golang.org/protobuf和google.golang.org/grpc的 minor 版本兼容性——v1.60.0的grpc要求protobuf至少v1.34.0，否则protoc-gen-go生成失败 - 避免在多个微服务间共享
go.mod文件；每个服务应有独立模块路径（如git.example.com/order），否则replace指令会互相污染
go-zero 的 goctl 生成代码 vs 手写 grpc-go 的依赖体积差异
本质区别不在框架本身，而在代码生成策略是否引入“运行时不可删”的间接依赖。比如 goctl rpc proto 生成的 zrpc client 默认带 resilience（熔断）、trace（Jaeger 集成）等能力，哪怕你没配，相关包仍被 import 进来。
手写 grpc-go 时，你可以只 import google.golang.org/grpc 和 google.golang.org/protobuf，其余全按需添加。
立即学习“go语言免费学习笔记（深入）”；
-
go-zero项目中若不需要熔断，得手动删掉生成代码里的zrpc.MustNewClient调用，并移除github.com/zeromicro/go-zero/zrpc/resilience相关 import；否则go list -f '{{.Deps}}' ./...会显示它仍在依赖树中 - 手写
grpc-go服务，go list -m -f '{{.Dir}}' github.com/golang/protobuf返回空？说明你用的是google.golang.org/protobuf，旧版golang/protobuf已被弃用，强制替换会导致protoc-gen-go版本错配 - 二者编译后二进制体积差异可达 3–5MB：主要来自
go-zero内置的prometheus、jaeger、redis客户端默认链接；用go build -ldflags="-s -w"可压缩，但无法删减已 import 的符号
微服务间 proto 共享导致的模块循环依赖怎么破
不是靠 replace 或 go mod edit -replace 硬解，而是靠物理隔离 + 协议下沉。只要两个服务共用同一份 user.proto，就必然面临谁来维护、版本如何同步的问题；一旦 A 服务升级字段类型，B 服务不更新就会 panic。
典型错误：把所有 .proto 放进一个叫 shared-proto 的 Git 仓库，然后在各服务 go.mod 里 replace github.com/org/shared-proto => ./proto ——这会让 go mod vendor 失效，且 CI 中无法保证各服务使用同一 commit。
- 正确做法是让每个服务只保留自己消费的
.proto副本（如order-service/proto/user.proto），并通过 CI 脚本自动从主干同步——例如用git subtree pull或gh repo clone下载指定 tag 的 proto 文件 - 如果必须复用，用
buf管理buf.yaml，定义deps引用远程buf.buildregistry，而不是本地replace；这样go mod不感知 proto 依赖，只管生成后的 Go 代码 - 禁止在 proto message 中引用其他服务的 message 类型（如
order.proto里写user.User）；跨服务数据交换一律用 flat 字段或 DTO，例如int64 user_id = 1;而非user.User user = 2;
go mod vendor 在微服务 CI 中为何常失效
因为 vendor 不是“冻结依赖”，而是“复制当前 go.sum 记录的所有包”。一旦某依赖包在 GOPROXY 上被覆盖（如作者删了 tag、重推同名版本），go mod vendor 就会拉不到原来的内容，校验失败。
更隐蔽的问题：某些框架（如早期 go-zero）生成的代码里硬编码了 github.com/zeromicro/go-zero@v1.5.0，但你本地 go.mod 锁的是 v1.5.1，vendor 时会冲突。
- CI 中优先用
go mod download+GOPROXY=direct拉取，再go mod verify校验完整性；vendor仅用于离线构建场景，非常规推荐 - 若必须用
vendor，在go.mod顶部加注释标明// vendor verified at 2026-07-15T10:00:00Z，并让 CI 检查该时间戳后是否有新版本发布 -
go-zero用户注意：goctl生成的etc/xxx.yaml配置文件里若含redis.Host这类字段，go mod vendor不会检查配置结构变更，但运行时会 panic；这类问题只能靠单元测试覆盖，不能靠模块系统发现
.proto，可能触发整个依赖树重算；而 go mod 不报错，直到 runtime 才 panic: interface conversion: interface {} is nil。 
