真正该拆包的信号是依赖无关模块、测试过慢或多人频繁冲突；应按可变性职责边界拆分，接口声明靠近使用方，避免循环导入。
拆包前先确认是否真需要拆分
Go 项目里一个 pkg/ 下塞几十个文件，不等于必须拆。Go 的包机制本就鼓励“小而专注”，但盲目按目录层级或功能名词拆（比如硬拆出 usermodel、userrepo、userservice）反而增加维护成本。真正该拆的信号是：go list -f '{{.Deps}}' ./pkg/user 显示依赖了大量无关模块；或者 go test ./pkg/user/... 跑一次要 8 秒以上且多数测试在 mock 外部依赖；又或者多个团队同时改 pkg/user 频繁冲突。
按职责边界而非名词拆，优先隔离可变性
不是“用户相关代码放一起”，而是“哪些部分会因数据库换型而改”“哪些会因 HTTP API 升级而动”“哪些逻辑永远只读不写”。典型做法：
-
pkg/user/core：纯领域模型 + 业务规则（如User.IsValid()、CalculateScore()），不依赖任何外部库，可单独测试 -
pkg/user/infra：仅含数据库驱动、Redis 客户端封装、第三方 HTTP client（如调用 auth service），所有实现都通过 interface 注入 -
pkg/user/app：用例层（Use Case），组合core和infra，定义输入输出 DTO，不含任何框架细节 - HTTP/Gin 相关代码全放在
cmd/api/handler或internal/handler，和业务逻辑物理隔离
接口定义位置决定耦合方向
谁依赖谁，看 interface 声明在哪。错误做法：在 pkg/user/infra 里定义 type UserRepository interface，再让 pkg/user/app 实现它——这会让应用层反向依赖基础设施层。正确做法：
- 接口声明在
pkg/user/core或pkg/user/app（靠近使用方） -
pkg/user/infra只提供 struct 实现，不声明 interface - 构造时用依赖注入（如 wire 或手工 NewXXX 函数）把 infra 实现传给 app 层
这样 core 和 app 编译不依赖数据库驱动，测试时可直接传入内存实现。
立即学习“go语言免费学习笔记（深入）”；
小心跨包循环导入和内部包滥用
Go 不允许循环 import，但容易在拆包时误触。常见陷阱：
-
pkg/user/core引用了pkg/order/core的某个类型，反过来pkg/order/core又想用pkg/user/core.User→ 必须抽离共享类型到pkg/domain，且该包不能依赖任何其他业务包 - 用
internal/xxx拆分时，误让internal/repo依赖internal/handler→internal只能向下依赖，不能平级或向上 - 为复用一点工具函数，新建
pkg/util，结果里面混了日志配置、HTTP 工具、加密逻辑 → 拆成pkg/xlog、pkg/xhttp、pkg/xcrypto，否则一个改动牵连全部
每次 go build ./... 报错 “import cycle” 时，别急着加 _ 导入或改名，先画两秒依赖图——90% 的循环都源于接口定义位置错了。
