Go多module项目中，go.mod应仅放在需独立版本、发布、测试或权限隔离的边界层：根目录（管理整体依赖与replace）、独立复用模块（如pkg/auth），而internal子目录是否设go.mod取决于跨团队协作需求；错误做法是为整洁强行拆分导致循环依赖。
Go 多 module 项目里，go.mod 文件到底该放在哪几层？
不是每个子目录都配一个 go.mod，而是只在真正需要独立版本、发布、测试或权限隔离的边界上建 module。比如 internal/user 和 internal/order 如果长期共演进、不单独发版，就该共用根 module；但若 pkg/search 是通用搜索引擎 SDK，要被其他公司项目引用，那就必须有自己的 go.mod。
常见错误是：为“看起来整洁”而强行拆，结果每个 internal/xxx/go.mod 都 require 主模块，形成循环依赖或 require internal/xxx: version is required 报错。
- 根目录
go.mod管理整体依赖和 replace 规则（开发期必需） - 独立复用模块（如
pkg/auth、pkg/eventbus）各自带go.mod，module path 必须全局唯一（如github.com/org/pkg/auth） -
internal/下业务子模块是否建 module，取决于协作模式：跨团队维护 → 建；单团队迭代 → 不建，靠包级接口 + 依赖方向约束更轻量
为什么 replace 在本地开发中不可替代，又极易误提交？
replace 是单仓库多 module 开发的生命线——它让 pkg/logging 还没打 tag，cmd/api 就能直接用它的最新改动。但 CI 构建时若残留 replace，会跳过语义化版本校验，导致线上环境行为漂移。
- 开发时：根
go.mod中写replace github.com/org/pkg/logging => ./pkg/logging - CI 流程必须加检查：运行
go mod edit -json | jq '.Replace'，非空即失败 - 上线前手动清理或用脚本自动移除：
go mod edit -dropreplace=github.com/org/pkg/logging - 别用
//go:build或条件编译绕过 replace —— 它不解决根本问题，反而掩盖依赖不一致
跨 module 调用时，interface 定义放哪才不会引发循环引用？
把 UserRepository 接口放在 internal/user/domain，然后让 internal/order import 它？立刻触发循环：order 需要 user 接口 → user 又可能依赖 order 的事件类型。真正的解耦点不在“谁定义接口”，而在“谁拥有接口所有权”。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 接口必须定义在调用方所在 module 内（例如订单服务需要查用户 →
internal/order/port定义UserReader） - 被调用方（user 模块）只实现该接口，不 import 订单代码；实现放在
internal/user/adapter/orderport，由主程序组合 - 公共基础类型（如
ID、TimeRange）可抽到独立pkg/typesmodule，但禁止放业务逻辑或领域行为 - 用
go list -f '{{.Imports}}' ./internal/order | grep user定期扫描隐式依赖
桥接模式在多 module 场景下怎么避免“抽象层污染”？
桥接本质是组合接口，但当 AlertService 和 SMSNotifier 分属不同 module 时，若 AlertService 的构造函数参数类型是 sms.SMSNotifier，那就彻底破坏了桥接意义——抽象层反而强绑实现细节。
- Notifier 接口必须由使用方（alert module）定义，例如
pkg/alert/notifier.go里声明type Notifier interface { Send(...) - 具体实现（
pkg/sms）只 importpkg/alert，实现该接口；不能反向 import - 启动时在
cmd/main.go组合：alert.NewService(sms.NewNotifier())，这里才是依赖注入点 - 如果多个 module 都要发通知，就提取
pkg/notification作为共享契约 module，但仅含接口和基础 DTO，不含任何实现
最易被忽略的一点：多 module 不等于自动解耦。没有接口定义权归属意识、没有 replace 清理机制、没有依赖方向硬约束，再多的 go.mod 也只是一堆互相拽着脚的目录。模块边界最终由人来守护，不是由工具自动生成。
