Go编译器对import cycle零容忍，必须通过重构依赖图使其成为DAG；定位需借助go list或Go 1.21+的闭环提示；解法包括接口抽象+依赖注入、提取公共类型至独立包、合并高耦合包或按层级重构。
Go 编译器对 import cycle not allowed 是零容忍的——它不是警告，不是运行时问题，而是编译期立即终止。你没法“绕过”，只能让依赖图变成有向无环图（DAG）。关键不在于删掉某行 import，而在于识别哪一层抽象缺失、哪个包职责越界。
怎么一眼定位循环路径
Go 1.21+ 会直接输出完整闭环链，例如：
import cycle not allowed:
package auth imports package user
package user imports package notification
package notification imports package auth
旧版本没这么友好，就得手动排查：
- 执行
go list -f '{{.ImportPath}}: {{.Imports}}' ./...，扫一遍所有包的Imports字段，找 A→B→A 这类短链 - 重点检查
*_test.go文件：测试包常同时 import 被测包和 mock 工具，而 mock 工具又 import 了业务类型，极易成环 - 留意
replace或vendor：同一逻辑包被不同路径引入（如github.com/x/y和./y），会让编译器误判为两个包并形成环
用 interface + 依赖注入反转依赖方向
这是最常用也最干净的解法，适用于“一个包需要调用另一个包的逻辑，但对方也要回调”的场景（比如 service 发事件，event 处理完要更新 service 状态）。
- 接口不能定义在任一业务包里（比如放在
service包中，让event去 import 它——这仍是反向依赖） - 必须新建独立包（如
pkg/contract或internal/handler），只放最小契约：type StatusUpdater interface { Update(id int) error } - 具体实现方（如
service）实现该接口，但不暴露包名；调用方（如event）只依赖接口，不 import 实现包 - 组装交给
main：用event.New(event.WithHandler(svc))这类方式传入，而非在event包内直接 new service
把共用结构体/错误/常量提到 third 包
当两个包互相 import 只是因为共用一个 type User struct 或 var ErrNotFound = errors.New("not found")，说明它们本不该直接耦合。
- 新建
pkg/domain或pkg/types，把 DTO、error var、核心 enum 全移进去 - 确保这个包是“叶子节点”：它不能 import 任何
infra、handler或业务 service 包，否则只是把环往下挪了一层 - 如果共用逻辑较重（比如校验函数），考虑用
internal包隔离：它能被同模块子包引用，但对外不可见，避免污染外部 API
合并或重构包边界比硬拆更有效
有时候强行拆包反而制造循环。比如 user 和 profile 包反复互引，大概率说明它们本就属于同一领域模型。
- 把高度耦合的结构体、方法、测试放回同一个包（如
pkg/user），用文件名区分关注点（user.go、user_profile.go、user_test.go） - 如果合并后包过大，再按访问层级切分：比如
pkg/user/model（纯数据）、pkg/user/service（不含 repo 实现）、pkg/user/repo（只依赖 model） - 警惕“伪分层”：
handler → service → repo → model看似单向，但如果repo里又 importservice来触发回调，那只是把环藏在了深层
真正难的不是写代码破环，而是判断“这个接口该放哪儿”“这个结构体到底属于谁”。每次遇到 import cycle，都该停下来问一句：这两个包的边界，是不是本来就不该存在？
