包职责过重表现为：user包同时处理DB查询、JWT解析和HTTP路由，order包混杂模型定义、校验、支付回调与日志；测试需mock多类依赖；go list显示大量非业务依赖；新增功能需修改多个文件并影响其他模块构建。
包职责过重的典型表现有哪些
不是文件大就叫“重”，而是看它是否被迫干了多件不相干的事：user 包里既写 DB.Query 又解析 JWT token 还暴露 HTTP handler，这就是职责过重；order 包同时定义模型、校验规则、支付回调逻辑和日志埋点，改一个字段就得测全部——这类包往往测试难跑、改起来心慌。
- 单元测试文件里要 mock 数据库、HTTP client、时间服务三类依赖
-
go list -f '{{.Deps}}' ./user输出一堆非业务相关包（如net/http、crypto/jwt） - 新增一个“用户导出 Excel”功能，却要动
user/model.go和user/handler.go两个文件，还顺带影响payment的构建
按业务域而非技术层来划分包名
别一上来就建 handler、service、repository 三层目录——这在 Go 里容易催生循环依赖，也模糊了业务边界。真正该拆的是“谁在做什么事”：注册、登录、密码重置是用户侧动作，但“发送短信验证码”属于通知能力，应归到 notify 包；“查询订单列表”是订单动作，“扣减库存”却是库存动作，它们不该挤在同一个包里。
- 包名必须小写、单数、语义明确：
user✅，users❌，core❌，common❌ - 目录名和包名严格一致，
./auth下必须是package auth - 接口定义放在调用方：比如
order包需要扣库存，就定义type InventoryClient interface { Reserve(ctx context.Context, sku string, qty int) error }，由inventory包实现
如何安全地把大包拆开而不引发循环依赖
最常见错误是：拆着拆着发现 user/repository.go 用了 order.Service，而 order/service.go 又调了 user.GetByID，Go 编译直接报 import cycle not allowed。这不是拆错了，是没处理好依赖方向。
- 用 interface + 依赖注入替代直接 import：把被依赖方的能力抽象成接口，定义在调用方包内，实现放在被调方
- 避免跨包共享错误类型：别让
user.ErrNotFound在payment里被 switch 判断，统一用标准errors.Is(err, user.ErrNotFound)或自定义错误码 - main 包负责组装：所有具体实现（如
mysql.UserRepo、twilio.NotifyClient）只在main.go或cmd/下初始化并传入，业务包之间不互相 new 实例
哪些情况其实不该拆包
看到 user.go 有 800 行就急着拆，反而可能制造更多麻烦。Go 的包粒度本就偏粗，关键在“职责是否单一”，不在行数。
立即学习“go语言免费学习笔记（深入）”；
- 纯数据结构包（如
model）：只含 struct、const、简单方法（func (u User) FullName() string），没副作用、无外部依赖，哪怕 20 个 struct 放一起也 OK - 工具函数慎提：别因为两个包都用了
strings.TrimSpace就抽个util，优先考虑内嵌或组合；真要提，确保它完全无状态、不依赖任何业务逻辑 - 刚起步的 MVP 项目：先跑通流程，等出现明显维护痛点（比如改个登录逻辑要动 5 个地方）再拆，别预设架构
最容易被忽略的是：拆包后没同步更新 go.mod 的 require 版本，或者忘了把原包里导出的变量/函数从新包里重新导出——结果调用方编译失败，还以为是拆错了。动手前先 go list -u -m all 看一眼依赖树，比什么都实在。
