Go禁止包级循环依赖，编译期直接报错，须通过提取公共抽象层、接口解耦与依赖注入重构破除，禁用replace绕过，用go list和go mod graph定位验证。

Go模块依赖图里出现循环引用，编译直接报错怎么办

Go 的包级循环依赖在编译期就拦住你，不是运行时才暴露——这是好事，但容易让人卡在“改哪边”的纠结里。关键不是删代码，而是识别谁该为抽象负责。

• 用 go list -f '{{.Deps}}' ./... | grep yourpkg 定位哪个包在双向 import
• 如果 user.Service 和 order.Repository 互相 import，说明它们本不该同属一个领域层；得把共用逻辑抽成 shared/domain.Event 或定义在 user 包里的 order.OrderReader 接口（注意：接口定义要放在更稳定的包，比如 domain 或 usecase）
• 别用 replace 绕过问题——它只是让编译通过，掩盖了设计缺陷；真正解耦后，replace 才该用于本地联调

internal 包被误当成“模块隔离工具”，结果越拆越乱

internal 是编译器强制的访问控制开关，不是模块划分标准。把它当边界画线，反而会让 domain 层和 infrastructure 层在同一个 internal/xxx 下继续紧耦合。

• internal/handler 不该直接 new infrastructure/mysql.UserRepo，哪怕它们都在 internal 下——这违反了依赖倒置
• 真正该隔离的是职责：把 entity.User 放 internal/entity，把 UserRepository 接口放 internal/usecase，实现放 internal/infra/mysql，三者之间只靠接口通信
• 如果发现 internal/infra 里的代码被 internal/handler 直接调用，说明分层失败；此时加再多 internal 目录也没用

单体项目里硬切 Go Module，导致版本发布雪崩

一个 go.mod 文件不等于一个服务，也不等于一个可独立发布的单元。过早按业务域建多个 module，会让 go get、CI 构建、跨 module 升级变成噩梦。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 先用单个 go.mod + 多 cmd/ 入口（如 cmd/userapi、cmd/usersvc）演进：二进制分离部署，共享 domain 和 usecase，避免重复逻辑
• 只有当两个部分必须不同步发版（比如用户中心每月发一次，风控规则每天发三次），才值得拆 module；否则所有变更都得同步 bump 版本号
• 若真要拆，用 go.work 管理本地多 module，而不是靠一堆 replace 指令——后者在 CI 环境下极易失效，且 IDE 跳转会断

服务间 HTTP 调用写死地址，本地调试全瘫痪

硬编码 "http://order-svc:8080" 看似简单，实际让整个调用链失去可观测性、重试能力和本地验证路径。

立即学习“go语言免费学习笔记（深入）”；

• 所有下游访问必须封装成 client 接口，例如 type OrderClient interface { GetOrder(ctx context.Context, id string) (*Order, error) }，实现里才决定是走 HTTP 还是 gRPC
• client 初始化必须由 DI 容器（如 dig）或构造函数统一注入，不能在 handler 里 &http.Client{} ——否则测试时没法 mock
• 生产环境用 Consul DNS SRV 或 Kubernetes Headless Service，开发环境配 hosts 或 docker-compose network 别名；绝对不要在 config.json 里存 "order_service_url"

最常被跳过的一步是：在拆之前，先跑一遍 go mod graph 看真实依赖流向，再对照业务语义判断哪些依赖本不该存在。代码没动，但依赖图已经暴露了架构裂缝。