go包设计核心是依赖单向（具体→抽象）、职责内聚、接口由使用方定义、go.mod表契约。需避免隐式实现依赖，按业务概念组织包，接口随调用需求定义，依赖版本精准约束。
Go 语言的包设计不是单纯的技术组织问题，而是影响可维护性、可测试性和演进能力的核心实践。关键在于用最小且明确的依赖关系，配合清晰的抽象边界，让包既能独立演化，又便于组合与替换。
依赖方向必须单向：从具体到抽象
Go 没有接口继承或泛型约束（早期版本），但可通过依赖倒置原则控制耦合。一个包若依赖另一个包的 具体类型或实现，就容易被绑定；应改为依赖 本包定义的接口，由外部注入符合该接口的实现。
- 例如：日志包不应直接调用
log.Printf，而应定义Logger接口，并接受其实现作为参数 - 数据库访问层不暴露
*sql.DB，而是封装为DataStore接口，隐藏驱动细节 - 避免跨包使用对方的结构体字段或未导出方法——这等于隐式依赖实现细节
包粒度以“职责内聚”为准，而非功能相似性
把所有工具函数塞进 util 包，或把所有 HTTP 相关逻辑放在 http 包，是常见反模式。Go 的包应围绕一个明确的业务或领域概念组织，其导出项共同支撑同一抽象目标。
-
payment包导出Processor接口、Pay()函数、ErrInsufficientFunds错误，而不是混入格式化金额或生成订单号的通用函数 - 若某函数只被包内一个文件使用，考虑是否应私有化；若被多个无关包高频复用，再评估是否抽成独立小包（如
id、timeutil） - 包名用名词，小写，短而达意（
auth、cache、search），不带pkg、module等冗余后缀
接口定义在使用方，而非实现方
这是 Go 包设计中极易被忽略的关键点。接口不是为了“统一实现”，而是为了“解耦调用”。谁需要抽象，谁就定义接口；实现包只需满足该接口，无需提前知晓。
立即学习“go语言免费学习笔记（深入）”；
- 支付服务调用方（如订单服务）定义
payment.Provider接口，再传给支付包的初始化函数 - 支付包本身不声明任何接口，只提供一个满足该接口的具体类型（如
stripe.Provider） - 这样订单服务可轻松切换为
paypal.Provider，而支付包完全无感知，也不需修改 import 或版本升级
go.mod 是契约，不是清单
go.mod 中的依赖版本不是越新越好，也不是越少越好，而是表达当前包能正确工作的最小兼容集合。主模块应显式约束间接依赖（通过 require + // indirect 注释或 replace），防止下游意外升级破坏行为。
- 避免在库包中使用
replace指向本地路径——这会让使用者无法构建 - 若依赖某个模块的 v2+ 版本，请确保其已发布语义化标签（如
v2.1.0），并用module/path/v2形式导入 - 定期运行
go list -u -m all检查可升级项，但升级前务必验证接口兼容性与行为变更（尤其context、io等基础包的细微改动）
不复杂但容易忽略：好的包设计不是一开始就画好架构图，而是在每次新增依赖、导出符号或拆分文件时，问一句——这个依赖是否必要？这个类型/函数是否属于这个包的抽象职责？它是否能让调用方更简单，而不是更难理解？
