go build 报 import cycle not allowed 时，可用 go mod graph 快速定位回边，或用 go list -f '{{.importpath}} -> {{join .imports " -> "}}' ./... 结合 grep 分析导入路径；测试文件、embed 和 generate 代码可能隐式引入循环依赖。
循环依赖报错时，go build 显示 import cycle not allowed 怎么快速定位
Go 编译器不会告诉你哪条路径成环，只抛一句错误。最直接的办法是让工具画出导入图：go list -f '{{.ImportPath}} -> {{join .Imports " -> "}}' ./...，再用 grep 过滤可疑包名；更省事的是跑 go mod graph | grep -E 'pkgA|pkgB'，一眼看出 pkgA → pkgB → pkgA 这类回边。
常见错误现象：改了一个 utils 包，突然 model 包编译失败，但 model 明明没动 —— 很可能 utils 新增了对 model 的引用，而 model 早就在 import utils，只是之前没触发检查（比如新增了跨包方法调用）。
- 别信 IDE 的“当前文件无报错”，Go 的循环依赖是构建期整体检查，单文件保存不暴露问题
-
_test.go文件也算在 import 图里，有时测试文件偷偷引入了生产代码，又反向被生产代码 import，这种隐式环最难揪 - 如果用了
go:embed或//go:generate，确保生成代码没悄悄 import 回源包
接口该提进哪个包：放在调用方、实现方，还是新建 iface 包
接口不是越抽象越好，关键是控制依赖方向。原则就一条：接口定义必须放在「依赖它的一方」的对面包里 —— 也就是调用方不持有接口，实现方也不定义接口，而是由第三方（通常是上层或共享包）声明。
使用场景举例：HTTP handler 需要调用数据库操作，数据库实现是 repo/sql，handler 在 handler 包。这时接口 Repo 应该定义在 handler 所在模块的 contract 或 port 包里，而不是塞进 repo/sql。
立即学习“go语言免费学习笔记（深入）”；
- 放在实现方包里 → 调用方被迫 import 实现细节，违背依赖倒置
- 放在调用方包里 → 实现方得 import 调用方，包职责混乱，且容易引发循环（比如 handler 定义
Repo，repo/sql又想 importhandler做日志 - 新建
internal/port是稳妥选择，但注意：这个包不能 import 任何业务实现包，否则又绕回去了
重构包结构时，go fix 和 gofmt 解决不了哪些问题
go fix 只处理语言版本升级的语法迁移（如 errors.Is 替换），gofmt 只格式化，两者都不动 import 路径和符号引用。真正卡住重构的是符号可见性与路径变更的耦合。
典型翻车点：把 user.Service 从 service 包移到 domain/user，但其他包里还有 svc := &service.User{} 这种直接实例化，或者 service.NewUser() 这种工厂调用 —— 这些不会被自动更新，编译直接报 undefined: service.User。
- 先全局搜
"service.User"、"NewUser("、"&service.User{"，别只盯 struct 名 - 如果旧包还残留未删干净的
.go文件，go list ./...仍会把它纳入构建，导致 “已删包却还在报错” - Go 1.21+ 支持
go mod vendor后，vendor 目录里的旧路径不会自动刷新，得手动go mod vendor -v再核对
go list -deps 查出来的包顺序为什么和实际构建顺序不一致
因为 go list -deps 按 import 声明顺序输出，而真实构建顺序由编译器按依赖拓扑排序决定。前者是“人写的顺序”，后者是“机器算出的安全顺序”。当两个包互相 import（哪怕间接），go list 可能显示 A→B→C，但构建时 C 其实得先编译完才能轮到 B —— 这就是为什么你看着依赖链没问题，却依然报循环。
性能影响很实在：一个深度嵌套的 import 图会让 go list -deps ./... 卡好几秒，尤其带 //go:embed 的包；而 go build -x 输出的命令流才是真实执行路径，比任何静态分析都准。
- 别拿
go list结果当真理，它只是快照，不是调度器 - 加
-f '{{.Deps}}'会输出原始字符串切片，里面混着 _cgo_imports、标准库伪包，得过滤掉再分析 - 真要验拓扑序，用
go build -work -x 2>&1 | grep 'cd '看实际进入目录的顺序
