go mod exclude 不能解决微服务间循环 import，因其仅影响依赖版本选择，不干预编译期 import 图校验；真正有效的是通过独立 go.mod、抽离 internal/contract 契约、禁止跨服务 import 及回调注入来硬性隔离依赖。
go mod exclude 不能解决微服务间的循环 import
排除依赖不是用来绕过 import cycle 编译错误的——Go 编译器在解析 import 图时根本不会看 go.mod 里的 exclude，它只认源码里实际写的 import 语句。你写 exclude github.com/your/app/user v1.2.0，但只要 service/order 还 import github.com/your/app/user，而 user 又反过来 import order，go build 依然会报错：import cycle not allowed。
常见误用场景：
- 以为加了
exclude就能“假装没这包”，结果测试跑不通，因为_test.go文件里仍存在真实 import - 试图用
exclude强制降级某个间接依赖，却导致主模块里某处调用了已被移除的 API，编译通过但运行 panic - 在根模块 exclude 了子模块的版本，但子模块自己有独立
go.mod，exclude对它完全无效
微服务粒度下真正有效的依赖隔离手段
每个微服务应视为独立构建单元，其依赖边界必须靠目录结构和 Go 模块划分来硬性约束，而不是靠 go mod 指令软性干预。
- 为每个服务建单独
go.mod：比如service/user/go.mod、service/order/go.mod，彼此不共享顶层go.mod - 禁止跨服务目录直接 import：不允许
service/order/handler.go出现import "github.com/your/app/service/user"这类路径 - 契约复用走
internal/contract或api/目录：所有服务只 importgithub.com/your/app/api/user/v1，这个包不能 import 任何其他服务代码 - client 实现放在各自服务内：
service/user/client.go实现contract.UserGetter，但它不 export client 类型给别处用
如何安全地让某个微服务“看不见”另一个服务的实现
核心是把“需要知道”和“需要引用”拆开——服务 A 需要知道用户数据结构，但不需要知道服务 B 怎么存它；服务 A 需要触发用户更新通知，但不需要知道服务 B 的 handler 怎么写。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- DTO 和 error 定义必须抽到
api/下，且只含字段和 JSON tag，不带方法、不 import 其他服务 - 接口定义用最小契约：例如
type UserEventPublisher interface { PublishUserUpdated(ctx context.Context, u *contract.User) error }，而非type UserService interface { ... } - 注入点声明为函数类型或接口字段：
OnUserUpdated func(*contract.User) error，启动时由 main 组装，避免 service 层互相 import - 测试文件（
*_test.go）最容易偷偷引入反向依赖，检查时重点 grepimport.*user和import.*order
排查残留依赖的实操命令组合
清理完结构后，别信 go mod tidy 的输出，得验证是否真断开了引用链。
- 进到
service/order目录，运行：go list -f '{{.Imports}}' ./...，确认输出里没有github.com/your/app/service/user - 查有没有被忽略的测试依赖：
go list -f '{{.Imports}}' ./... | grep user，再加-tags integration重试 - 看依赖图是否干净：
go mod graph | grep -E "(user|order)"，理想情况只有它们各自指向api/和标准库 - 运行
go mod why github.com/your/app/service/user，如果返回main module does not need module，才算真正切断
最易被忽略的是测试文件和 build tag 条件下的 import——它们不参与默认构建，但会让 go mod tidy 误判依赖必要性，必须手动交叉验证。
