Gin路由文件import service触发import cycle的根本原因是包职责混杂，而非路由写法错误；应通过分层（router只import domain和handler、service接口定义在domain、错误统一收口至domain/errors）、接口抽象与依赖注入解耦，确保依赖单向（router→domain→service实现），禁止跨层直接import。
为什么 Gin 路由文件 import service 会触发 import cycle
不是路由写法错了，是包职责混了。常见场景：把 router/user.go 直接 import "./service/user"，而 service/user 又因日志、错误处理或回调需要 import "./router"（比如引用了 router.ErrInvalidInput 这类跨包 error 变量），立刻报 import cycle not allowed。Go 编译器不看函数是否实际调用，只要 import 链成环就拒绝编译。
关键点在于：路由层本不该知道 service 层的具体类型或错误变量；service 层更不该反向依赖路由定义的任何东西。
- 避免在
service/包里import任何router/、handler/或api/包 - 所有跨层 error 应统一放在
pkg/errors或domain/errors，且该包不能 import 任何业务包 - 路由文件只负责解析请求、调用 service 接口、封装响应——它不持有 service 实现，只持有一个 interface 引用
router/ 包里该 import 什么、不该 import 什么
router/ 是典型的“胶水层”，它必须能访问 handler 函数和 service 接口，但绝不能绑定具体实现。所以它的 import 列表应极简：
- 必须 import：
github.com/gin-gonic/gin、context、net/http、your-project/domain（含 DTO 和接口定义） - 禁止 import：
your-project/service、your-project/repository、your-project/infra—— 这些都该通过构造函数注入 - 如果用了
go list -f '{{.Imports}}' ./router输出里出现业务包名，说明结构已污染
示例正确结构：
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
// router/user.go
package router
import (
"github.com/gin-gonic/gin"
"your-project/domain"
"your-project/handler"
)
func SetupUserRoutes(r *gin.RouterGroup, h handler.UserHandler) {
r.POST("/users", h.CreateUser)
r.GET("/users/:id", h.GetUser)
}
如何让 handler.UserHandler 不引发循环依赖
handler 包常是循环高发区：它既要调用 service，又可能被 router import，还容易偷偷 import validator 或 middleware 中的自定义类型。解法不是删 import，而是分层收口：
-
handler包只 import：github.com/gin-gonic/gin、your-project/domain、your-project/service（仅接口，非实现） -
service接口必须定义在domain或contract包中，service包只做实现，不定义接口 -
handler的构造函数接收 service 接口作为参数，而非自己 new 具体实现 —— 这样它就不需要 importservice/impl - 测试时可直接传入 mock 实现，无需启动整个服务
错误示范：handler/user.go 里写 svc := &service.UserServiceImpl{} → 必然拉进 service 包；正确做法是 type UserHandler struct { svc domain.UserService }。
domain/ 包验证是否“干净”的实操命令
domain 是解耦核心，但它一旦污染，整个依赖树就失效。最简单的验证方式就是检查它的 import 列表是否可控：
- 运行
go list -f '{{.Imports}}' ./domain，输出应只含标准库（如errors、time）或空列表 - 若出现
your-project/service或your-project/router，说明有 struct 嵌套了 concrete type，或某处误用了svc.SomeMethod()而非 interface - 用
go list -f '{{.Deps}}' ./router | grep domain确认只有单向依赖：router → domain，没有 domain → router - 特别注意
*_test.go文件 —— 它们也会参与 import 解析，测试文件里写的import "./service"同样会触发循环
真正难的不是拆包，而是每次新增字段、方法或 error 时，下意识判断：这个东西，到底属于哪一层？放错一层，三个月后就会变成一个绕不开的闭环。
