Go中import过多导致难测试、难替换、难维护，根源在于高层逻辑直接依赖具体实现而非抽象接口；应让业务层定义接口、实现层导入具体包，通过构造函数注入依赖，并在main中统一初始化。
为什么 import 一多就难测试、难替换、难维护
Go 没有接口继承或依赖注入容器，但包之间直接 import 具体实现（比如 "github.com/foo/bar/storage"）会导致：测试时无法 mock 存储层、换数据库要改所有调用点、单元测试必须连真实 Redis。这不是 Go 的问题，是没把「谁依赖谁」想清楚。
用接口定义能力，而非导入具体包
关键不是少写 import，而是让高层逻辑只依赖抽象接口，把具体实现的创建和绑定推迟到程序启动时。
- 在业务逻辑包（如
service）中定义接口，例如：type UserRepository interface { GetByID(id int) (*User, error) Save(u *User) error } - 不要在
service包里import "github.com/xxx/redisrepo"—— 实现类放在另一个包（如repo/redis），它才 import 具体驱动 - 构造函数接收接口，不 new 具体类型：
func NewUserService(repo UserRepository) *UserService { return &UserService{repo: repo} }
初始化时传入实现，而非包内硬编码
避免在 service 层写 repo := redisrepo.NewClient(...)。这类初始化逻辑应统一收口到 main.go 或 cmd/ 下：
- 不同环境可注入不同实现：
// main.go db := sql.Open(...) redisClient := redis.NewClient(...) svc := service.NewUserService(repo.NewSQLUserRepo(db)) // 或 svc := service.NewUserService(repo.NewRedisUserRepo(redisClient))
- 测试时直接传 mock：
mockRepo := &MockUserRepository{} svc := service.NewUserService(mockRepo) - 注意：接口变量本身不引发循环 import；但若两个包互相
import接口和实现，就会出错 —— 确保接口定义在被依赖方（如service），实现放在依赖方（如repo）
警惕「接口泛滥」和「过度抽象」陷阱
不是每个函数都要抽接口。只有以下情况值得抽象：
立即学习“go语言免费学习笔记（深入）”；
- 需要多套实现（如本地缓存 vs 分布式缓存）
- 涉及 I/O 或外部服务（DB、HTTP、消息队列）
- 测试时必须隔离（比如发邮件、调第三方 API）
- 接口方法超过 3 个，或命名开始出现
XXXForTestXXXWithTimeout—— 说明设计粒度太粗，该拆了
真正难的不是写接口，是判断哪一层该切、哪一层该稳。很多团队卡在「repo 层要不要再抽象一层 DAO」——其实只要 UserRepository 能覆盖所有业务查询需求，就不必加中间层。
