真正可拆的模块需有明确职责、可独立测试、接口稳定且不依赖其他业务包私有结构体；判断标准是复制目录到新仓库并删跨包import后单元测试仍通过。
拆分前先确认模块边界是否真实存在
很多团队在 Go 项目里强行“按目录拆包”，结果只是把 main.go 拆成一堆 pkg/xxx/xxx.go，但包之间仍高耦合、循环依赖、共享大量 internal 类型——这不是拆分，是切片。真正可拆的模块，必须满足：有明确职责（比如只处理支付网关适配）、能独立测试、对外暴露极少且稳定的接口、不直接依赖其他业务包的私有结构体。
判断方法很简单：把该目录下所有文件复制到新仓库，删掉所有跨包的 import，看还能不能跑通单元测试。如果不行，说明边界没理清，先重构再拆。
用 Go 的 vendor 机制替代盲目上 monorepo 工具
别一上来就引入 goreleaser、bazel 或自建 monorepo。Go 原生 go mod vendor + 显式版本控制，对多数中型团队更轻量、更可控。
- 拆出的模块发布为独立
module，要求go.mod中module名带完整域名（如github.com/org/payment），避免本地 replace 混淆 - 主项目通过
require github.com/org/payment v0.3.1固定小版本，禁止使用latest或master - 本地开发调试时，用
replace github.com/org/payment => ../payment，但上线前必须删掉 ——replace不进 vendor，CI 构建会失败
接口定义必须放在被依赖方，而非调用方
这是 Go 拆包中最常踩的坑：A 包需要调用 B 的能力，于是 A 包里定义了 type PaymentService interface，再让 B 实现它。结果 B 被迫 import A，形成反向依赖。
正确做法是：B 包导出自己的核心接口（如 B.PaymentService），A 包用 func NewClient(svc B.PaymentService) 接收，不定义任何 interface。这样 A 只 import B，B 完全无感知。
示例：
// payment/pkg/service.go
package payment
type Service interface {
Charge(ctx context.Context, req ChargeRequest) (ChargeResponse, error)
}
// app/order/handler.go
package order
import "github.com/org/payment"
func NewHandler(paySvc payment.Service) *Handler { ... } // ← 依赖具体类型，非抽象定义
小心 context.Context 和 error 的跨模块传播
拆包后，context.Context 往往被层层透传，最后在底层模块里被 cancel 或 timeout，但上层无法区分是网络超时还是业务逻辑卡死；错误也常被简单 fmt.Errorf("failed to call payment: %w", err) 包裹，丢失原始类型和关键字段。
- 模块间传递
context.Context时，只加必要 key（如ctx = context.WithValue(ctx, traceIDKey, id)），禁止塞业务参数 - 错误应统一用自定义类型包装，比如
payment.Error实现IsTimeout() bool方法，调用方靠类型断言或errors.Is(err, payment.ErrTimeout)判断，而不是字符串匹配 - 日志打点统一用结构化字段（
log.Info("payment charged", "order_id", oid, "status", status)），避免模块间日志格式不一致
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
