GoLand中无法直接显示完整import环，需用命令行工具定位：执行go list -f '{{.ImportPath}} -> {{join .Imports " -> "}}' ./... | grep -E 'pkgA|pkgB'查看导入链，或go mod graph | grep -E 'pkgA.*pkgB|pkgB.*pkgA'直筛回边；注意_test.go文件、replace/vendor影响及接口应置于独立contract/internal/port包中。
go build 报 import cycle not allowed，GoLand 里怎么快速定位闭环路径
GoLand 自带的语法检查不显示完整 import 环，只标红却不告诉你哪几行连成了环。真正能定位的，是命令行工具，不是 IDE 界面。
执行这句命令，直接暴露所有包的导入边：
go list -f '{{.ImportPath}} -> {{join .Imports " -> "}}' ./...
再配合 grep 过滤你怀疑的包名，比如：
go list -f '{{.ImportPath}} -> {{join .Imports " -> "}}' ./... | grep -E 'user|order|repo'
如果看到类似 github.com/x/user -> github.com/x/repo -> github.com/x/order -> github.com/x/user 这样的链，就是闭环源头。
- 别忽略
*_test.go文件——它们参与 import 图计算，错误信息里带(test)后缀的，八成是测试代码偷偷拉了生产包又反向被引用 - 用
go mod graph | grep your-module辅助验证：若同时出现your-module/a your-module/b和your-module/b your-module/a两行，基本坐实 - 加
-mod=readonly参数运行，避免go list查线上路径而非实际构建路径（尤其用了replace或vendor）
接口该提进哪个包：contract、service 还是 internal/port
接口放错位置，等于把循环依赖埋得更深。不是“谁用就放谁那”，而是必须放在双方都可 import、但又不依赖任何业务实现的包里。
常见错误：
- 放在
service包里 →repo不得不 importservice，结果又触发新环 - 放在
repo包里 →handler被迫 import 数据库细节，违背依赖倒置
正确做法是新建 internal/port 或 contract，且这个包里：
GoLand 2026.1.1
下载
GoLand 2026.1.1 是 2026.1 发布后的首个维护修正版本，适合已经开始体验 2026.1 新功能并希望同步补丁的开发者。它更适合用于入门项目、现有项目迁移测试和 IDE 行为验证。
- 只 import
context、error、基础类型和自己定义的轻量 DTO（如type CreateUserReq struct{ Name string }） - 绝对不 import
repo、service、handler等任何业务包 - 接口方法避免塞
Save()、Delete()这类写操作——那是职责越界，该转为 event/command 模式
重构后怎么确认循环真被破除了
光看 go build 成功不够。隐性残留可能还在，比如 go.mod 里 replace 导致同一包被多个路径引入，或测试文件没同步清理。
执行这两步交叉验证：
-
go list -f '{{.ImportPath}}: {{.Imports}}' ./...扫一遍所有包，人工确认没有双向引用（比如A导入B，B也导入A） -
go mod graph | grep your-module，重点看有没有反向指向自己的边（如your-module/repo your-module/service和your-module/service your-module/repo同时存在）
如果仍报错，检查 go.mod 是否有重复 replace 条目，或者是否漏删了某个 _test.go 里的 import。
什么时候不该强行拆接口，而该合并包
不是所有双向引用都需要抽象接口。强行拆分会增加不必要的间接层，反而让调用链更难读。
典型该合并的信号：
-
User和Team结构体互相嵌套指针，方法互调频繁 - 两个包的测试文件共用大量
setup逻辑 - 一个包同时 import 数据库驱动（如
github.com/go-sql-driver/mysql）和 HTTP handler（如net/http），还被 service 层直接调用
这种场景下，合并为 pkg/domain 或 pkg/models 更合理——本质是领域边界模糊，不是技术问题，是设计问题。
