Go编译器对import循环直接报错而非警告，需用go list定位闭环路径；应将共享结构体提至model包，定义策略接口由调用方声明、被调用方实现；强耦合类型如Person/Team可合并至同一model包。
Go 编译器遇到 import cycle not allowed 就直接拒绝编译，不是警告，也不是运行时问题——你改的每一行代码，只要让依赖图闭合成环，build 就会当场失败。这不是环境或缓存问题，是架构在提醒你：两个包的职责已经拧在一起了。
用 go list 快速定位闭环路径
肉眼扫 import 语句大概率漏掉间接依赖（比如 A → B → C → A）。最稳的办法是用 Go 自带工具逐层展开：
- 运行
go list -f '{{.Deps}}' ./service/order查看order直接依赖哪些包 - 对每个输出的包再执行一次，比如发现它依赖
user，就立刻跑go list -f '{{.Deps}}' ./service/user - 一旦某次输出里出现之前见过的包名（比如又看到
order），闭环就锁定了 - 别忽略
*_test.go文件——测试包也算独立包，user/service_test.goimportorder可能就是隐藏源头
把 User 和 Order 这类结构体提到 model 包里
当两个服务都要用 User 字段、又要避免互相 import，复制结构体是毒药，硬塞进任一业务包会引发反向依赖。正确做法是新建一个极简包：
- 包名建议叫
model或domain，只放type User struct{...}、const ErrInvalidUser = ...、var ErrNotFound = errors.New(...) -
model包不能有func (u *User) DoX()，也不能import任何业务包（验证方式：go list -f '{{.Imports}}' ./model输出应为空或仅含errors、time等标准库） -
service/user和service/order都 importmodel，但彼此不 import —— 依赖树变成单向发散 - 如果
model.User里开始出现SendWelcomeEmail()这种方法，说明边界已破，得立刻剪掉
在 order 包里定义 UserPolicy 接口，由 user 包实现
循环常发生在“我需要你能力，你也需要我数据”的场景（比如下单前校验用户状态，查用户时又想顺带读最近订单）。这时候别让双方互相调用，而是把契约定义权交给使用方：
立即学习“go语言免费学习笔记（深入）”；
- 在
service/order/port.go里写type UserPolicy interface { CanPlaceOrder(uid string) bool }—— 接口属于 order 的需求，位置就在 order 包内 -
service/userimportservice/order（只为了这个接口），然后让user.Service实现UserPolicy -
order.Service通过构造函数注入UserPolicy实例，不 new、不 importuser - 接口方法参数必须是基础类型或
context.Context；禁止塞Save()、Delete()这类写操作——那不是策略，是越界
合并 user 和 team 这类天然强耦合的包
不是所有循环都靠抽象能优雅解决。当两个类型必须互相嵌套、且从不单独存在时（比如 Person.Team 和 Team.People），强行拆包只会增加跳转和维护成本：
- 把
Person和Team合并进model包，用不同文件组织：model/person.go、model/team.go - 字段可直接引用同包类型：
type Person struct { Team *Team }、type Team struct { People []*Person } - 所有关联逻辑（如
team.AddMember()）、验证规则、生命周期管理，都集中在这个包内完成 - 如果合并后
model包开始 importservice或infra，说明它已超重，得立刻拆分
真正难的不是写接口或提 model，而是判断什么时候该合并、什么时候该抽象——这取决于类型是否共享同一业务语义和生命周期。一旦你在 model 里加了个 func (u *User) Notify()，或者在 port 接口里塞了 UpdateProfile()，循环就会换个姿势回来找你。
