拆分Go package应按职责边界而非文件大小——若包承担多个不相关职责（如user包混杂DB、HTTP、JWT等）则需拆，否则强拆反增负担；须同步处理导出符号、依赖方向、错误类型三件事。

拆分过大的 Go package 不是“把大文件切成小文件”，而是按职责边界重新组织代码结构——核心判断标准是：**这个包是否同时承担了多个不相关的业务或技术职责？** 如果答案是肯定的，就该拆；如果只是文件多但逻辑高度内聚（比如一个完整领域模型），强行拆反而增加认知负担。

识别高内聚低耦合的拆分边界

别数行数，要看代码在做什么。常见混杂场景包括：

• user 包里既有数据库 UserModel、HTTP handler、JWT 解析、密码哈希、邮件模板拼接——这至少该拆出 model、auth、notification
• order 包中混着订单状态机、支付回调处理、库存扣减、物流单生成——状态机和支付应独立，库存与物流通常属于其他限界上下文
• 所有工具函数塞进 util：字符串、时间、加密、HTTP 客户端全在一个包里——这类包极易变成循环依赖温床，应按用途拆为 strutil、timeutil、httpclient

关键信号：当你发现某个函数/类型被三个以上不同业务包频繁导入，它大概率该抽成独立包；反之，如果一个包只被一个上层包导入，且内部逻辑紧密关联（如 payment/alipay 下的签名、验签、异步通知解析），暂不需拆。

拆分时必须同步处理的三件事

只改目录结构不改代码，90% 会编译失败或引入隐性 bug。动手前先确认：

• 导出符号一致性：移走的函数若原被外部调用，要在旧包中加 type PaymentClient = alipay.PaymentClient 类型别名，或转发方法，避免调用方直接报错
• 依赖方向不可倒置：用 go list -f '{{.Deps}}' ./... 检查新包是否意外反向依赖了原包；若出现 service → repository → service，说明拆得不干净，要提取公共接口到 domain 或 model
• 错误类型收敛：分散的 ErrInvalidOrder、ErrOrderNotFound 应统一收口到 order/errors.go，新包只 import "myproject/order"，而非各自定义

避免踩坑：过度拆分与路径陷阱

新手常犯两类错误：

• 为拆而拆：把 user 拆成 user/model、user/dao、user/service——这是按技术层切，不是按业务域切，反而加剧耦合。DDD 原则下，user 本身就是一个限界上下文，其内部结构应由该上下文自治
• 路径与模块名不一致：比如目录是 pkg/auth/jwt，但 go.mod 中 module 名是 myproject/auth，会导致 import "myproject/auth/jwt" 报错。正确做法是让子目录路径严格匹配 module 路径，或使用 replace 在本地开发时映射

真正难的不是怎么拆，而是每次拆完后，用 go mod graph | grep yourpkg 看一眼依赖图——如果箭头指向混乱、出现环、或者基础包（如 model）依赖了业务包（如 payment），说明边界没划清，得回退重审。