拆分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。动手前先确认：
立即学习“go语言免费学习笔记（深入）”；
-
导出符号一致性：移走的函数若原被外部调用，要在旧包中加
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），说明边界没划清，得回退重审。
