Go项目应按业务域而非技术层划分package，如用户注册、订单创建等独立业务动作各自成包，interface定义放在调用方，package名与目录严格一致且小写，main包仅负责初始化。
按业务域而非技术层划分 package
Go 项目里最常见的 package 拆分误区，是照搬 Java 或 Spring 的「controller/service/dao」三层结构，结果导致 service 包越来越胖、跨 package 循环依赖频发、测试时不得不 mock 整个「层」。Go 更推荐以业务能力为边界——比如用户注册、订单创建、库存扣减这些独立可验证的业务动作，各自形成一个 package。
例如电商系统中，user 包不该只放 User 结构体和 CreateUser 函数，而应包含注册流程所需的全部逻辑：邮箱校验、密码哈希、事件发布（如 user.Registered）、甚至配套的 repository 接口定义（user.Repository）——只要它不依赖其他业务包的具体实现。
- 每个 package 应有明确的
go:generate注释或 README.md 说明其职责边界 - 避免出现
core、common、utils这类泛化包名；若真有共享逻辑，优先考虑内嵌类型或组合，而非导出函数 - 跨业务调用必须通过 interface（如
payment.Service）而非具体实现，且 interface 定义放在调用方 package 内（即「接口隔离原则」在 Go 中的实践）
package 名与目录路径严格一致，且小写无下划线
Go 要求 package 名必须与所在目录名完全匹配，且只能是小写字母、数字、下划线（但官方强烈建议不用下划线）。一旦写成 user_repo 目录却声明 package userrepo，就会触发 package "user_repo" does not match directory name 错误。
更隐蔽的问题是大小写混用：比如目录叫 User，但 Go 不允许大写开头的 package 名，go build 会直接失败。另外，某些 IDE 在重命名目录后可能缓存旧 package 名，需手动清理 go.mod 和 go.sum 并执行 go mod tidy。
- 新建 package 时，先建目录，再在目录下写
xxx.go，第一行必须是package xxx - 使用
go list -f '{{.Dir}}' ./...可批量检查所有 package 路径是否合规 - CI 中加入
find . -name "*.go" -exec grep -l "^package [A-Z]" {} \;防止大写 package 名被提交
避免跨 package 循环依赖：用 interface + callback 替代直接引用
当 order 包需要调用 inventory 扣库存，而 inventory 又要发事件给 order 更新状态时，就容易写出循环 import：order → inventory → order。Go 编译器会报错 import cycle not allowed。
解法不是加一层 event 包来中转，而是让 inventory 接收一个回调函数或 interface，由 order 实现并传入。例如：
package inventory
type OrderUpdater interface {
UpdateOrderStatus(orderID string, status string) error
}
func Reserve(ctx context.Context, repo Repository, updater OrderUpdater, orderID string) error {
// ... 扣减逻辑
return updater.UpdateOrderStatus(orderID, "reserved")
}
order 包里实现该 interface，并在调用 inventory.Reserve 时传入自身方法闭包。这样依赖方向始终是单向的：order → inventory，且 inventory 不感知 order 的具体结构。
- interface 定义放在调用方（
order），而非被调用方（inventory），避免被过度泛化 - 不要为解耦而提前定义大量空 interface；只在真实存在多实现或测试 stub 需求时才引入
- 用
go mod graph | grep -E "(order|inventory)"可视化依赖流向，快速定位隐式循环
main 包只做初始化，业务逻辑零代码
main 包唯一合法行为是解析配置、建立依赖树、启动服务。任何业务逻辑（哪怕只有一行计算）写进 main.go，都会导致该逻辑无法被单元测
试、无法被其他 binary 复用、且违反单一职责。
典型反例：main.go 里直接调用 http.HandleFunc("/pay", func(w http.ResponseWriter, r *http.Request) { ... })，把支付处理逻辑全塞进去。正确做法是把 handler 提炼为 payment.NewHandler(payment.Service)，并在 main 中仅负责组装和注册。
-
main包内禁止出现struct、func（除main()外）、var（除全局 flag 和 logger 外） - 多个 binary（如 CLI 工具、HTTP 服务、gRPC 服务）可共用同一套业务 package，仅靠不同
main包切换入口 - 用
go list -f '{{.Name}}: {{.Deps}}' ./cmd/...检查main是否意外依赖了非基础设施 package
Repository 接口放在 model 或 data 包，结果导致业务包被迫依赖数据层，彻底锁死架构演进。真正的解耦点永远在调用方。
