因为Go编译器在解析import声明阶段就构建依赖图，一旦发现A→B→A等闭环即刻终止编译，该检查是静态、硬性、不可绕过的，与运行时行为无关。
为什么import cycle not allowed没法绕过去
Go 编译器在解析 import 声明时就构建依赖图，只要发现 A → B → A（或更长的闭环），立刻终止编译。这不是运行时错误，也不受函数调用、变量使用、init() 执行顺序影响。哪怕只有一行 import "pkgB" 在 pkgA 里，而 pkgB 也 import pkgA，就直接失败。
- 报错信息里带完整路径链（Go 1.21+）：比如
import cycle not allowed: github.com/x/auth imports github.com/x/user, github.com/x/user imports github.com/x/notification, github.com/x/notification imports github.com/x/auth - 旧版 Go 不显示链路，只能靠
go list -f '{{.Deps}}' pkgA逐层查依赖 - 测试文件（
*_test.go）是高发区：它同时 import 被测包和 mock 工具包，而 mock 包又 import 了业务类型，极易隐式成环
用interface + 依赖注入切断双向调用
两个包互相需要对方能力（比如 service 要发事件，event 处理完要回调 service），不能靠“删 import”解决，得让依赖方向变单向。
- 把共用契约抽到独立包，如
pkg/contract或internal/handler，定义type EventHandler interface { Handle(e Event) error } -
service包实现该接口，但不暴露自身包名；event包只 importcontract，接收接口作为参数（如event.New(event.WithHandler(svc))） - 绝对避免把接口定义在被依赖方包内（比如在
service包里定义Callback接口，再让eventimport 它——这仍是反向依赖） - 主程序（
main）负责组装：它 import 两边，传具体实现进去，各业务包保持无状态
提取common 或 model 包收拢共享结构
循环常因共用 struct、error、常量引发，比如 user.User 和 order.Order 都要引用对方的 ID 类型。
- 新建
pkg/model（或pkg/domain），只放基础类型：type UserID string、type OrderID int64、var ErrNotFound = errors.New("not found") -
user和order都 importmodel，不再互相 import - 这个包必须是“叶子节点”：不能 import 任何 infra、handler、service 层代码，否则只是把环挪了个地方
- 如果已有
internal/目录，优先用它——Go 官方机制，能阻止外部模块越级引用
重构包职责边界比修 bug 更关键
循环依赖本质是职责划分模糊的信号。常见病灶包括：把 model、repo 实现、service 全塞进同一个
user/包，导致其他包一用就拉进整套依赖HTTP handler 直接调用 service 函数，而 service 又要调用 http client 发请求，形成隐式环
用
init()跨包注册 handler，看似没 import，但编译器静态分析仍能识别依赖关系-
按关注点分层：
model/（纯数据）、repo/（接口定义）、service/（业务逻辑）、transport/（API 层）
Golang Samber Hot下载在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
立即学习“go语言免费学习笔记（深入）”；
repo包只定义接口，不实现；postgres/包实现它，只 importmodel和repo拆分前先跑
go mod graph | grep your-module，确认当前依赖拓扑；重构后用go build ./验证是否真清除
真正卡住人的不是语法限制，而是把“谁该知道谁”想清楚。一个包不该既提供能力，又消费别人的能力——它要么暴露接口，要么实现接口，不能两边都占。
