没有“一键”拆包方案，需先判断是否该拆：通过go list和git blame检查重复依赖与多人混改；拆包时import路径须对齐module path；接口定义前置、禁止跨包struct引用；测试须随包迁移并用mock隔离。
先判断：这个包到底该不该拆？
别急着动代码，先跑两条命令看信号：
-
go list -f '{{.Deps}}' ./pkg—— 如果输出里反复出现github.com/someorg/log、github.com/someorg/db这类相同外部依赖，说明它在重复承担 infra 职责 -
git blame pkg/handler.go | head -10—— 如果前十行作者不重叠，且修改动机分别是“加个 prometheus metric”“修个 SQL 注入”“改前端返回字段”，说明多人在同一个文件里拧不同螺丝
满足任一条件，就该拆；否则，先重构包内结构，比硬拆更有效。
拆包时 import 路径必须对齐 module path
Go 没有命名空间，import 路径就是模块地址。常见错误是路径写成 ./internal/order 或 myproject/order，结果 go build 报 cannot find module providing package。
- 先在项目根运行
go mod init github.com/yourorg/monorepo（模块名必须和所有未来import前缀一致） - 新建子目录
order，把相关代码移进去后，所有.go文件顶部的import必须改成github.com/yourorg/monorepo/order - 如果旧包里有
init()函数，拆完要检查是否被多次执行——比如日志注册、HTTP handler 全局挂载，可能在多个包里重复触发
接口定义必须前置，不能暴露 concrete type
最常踩的坑：老包里定义 type Order struct { ID int }，新包直接 import "old/pkg" 然后传指针。结果一改 ID 类型，整个调用链崩。
立即学习“go语言免费学习笔记（深入）”；
- 在新包根目录建
contract.go，只放接口：type OrderService interface { Create(*OrderInput) error } -
OrderInput定义在新包内，字段精简、无副作用；老包负责用mapstructure或手动赋值转成自己内部 struct - 禁止新包
import老包的 struct；老包实现接口，新包只依赖接口
测试必须跟着包走，不能留“幽灵测试”
拆完发现 go test ./order 通过，但 CI 上订单逻辑出错？大概率是旧测试文件还在跑老代码。
- 删掉原
pkg/xxx_test.go，每个新包必须有自己独立的xxx_test.go，且package order和目录名严格一致 - 运行
go test -v ./order，确认只跑新包下的测试；用go test -run=^TestCreate$ ./order单测精准验证 - 测试里不要写
sql.Open或http.ListenAndServe—— 用 interface + mock，否则测试本质是集成测试，慢且不稳定
真正耗时间的从来不是剪切粘贴代码，而是厘清“谁该知道什么”——接口放哪、数据怎么流、错误怎么透出。这些决策点没法自动化，必须人来判。拆得越快，后期修循环依赖和类型不匹配的夜就越长。
