Go包应按业务域（如user、order）而非技术层划分，每个域独占package并对外暴露明确接口；跨域调用须通过interface或DTO；interface定义在调用方或contract包以控制依赖方向；禁用utils/common“上帝包”和xxxhelper反模式；main.go仅负责参数解析、依赖构造和启动调用。
拆分 package 时优先按业务域而非技术层
Go 的 package 不是 Java 的 package，它本质是编译单元，不是命名空间容器。强行按 controller/service/repository 拆成同级目录，会导致循环依赖、测试难 mock、重构成本高。
真正可持续的划分方式是：一个业务域（如 user、order、payment）独占一个 package，内部可自由组织结构，对外只暴露明确的接口和导出函数。
- 每个
package应有单一职责，例如user包负责用户生命周期，不掺杂权限校验逻辑（那是auth包的事） - 跨 domain 调用必须通过 interface 或 DTO，禁止直接 import 另一个 domain 的内部 struct
- 避免
internal/xxx这类“伪私有”设计——如果不想被外部用，就别导出；真要限制访问，用internal目录，但仅限于项目顶层的共享工具或框架胶水代码
interface 定义位置决定依赖方向
谁定义 interface，谁就掌握依赖主动权。常见错误是把 Repository 接口放在 service 包里，导致 service 依赖 repository 实现，违反了“依赖倒置”。
正确做法是：接口定义在调用方所在包，或更上层的 contract / port 包中；实现放在被调用方包内。
立即学习“go语言免费学习笔记（深入）”；
package user
type UserRepo interface {
GetByID(id int) (*User, error)
}
func NewService(repo UserRepo) *Service {
return &Service{repo: repo}
}
这样 user 包不依赖任何具体实现，测试时可传入 mock，数据库更换也只需替换 repo 实现，不影响业务逻辑。
避免 “God Package” 和 “Helper Hell”
两个高频反模式：utils 和 common 包快速膨胀，最终变成无法归类、不敢动、改一处崩一片的“上帝包”；另一个是每个小功能都单独建 xxxhelper，导致包数量爆炸、跳转迷失。
应对策略很直接：
-
utils包只收**无状态、纯函数、跨 domain 复用率极高**的代码，比如StrToBool、DeepCopy；带业务语义的函数（如FormatOrderID）必须归属对应 domain 包 - 拒绝
stringhelper、timehelper这类命名——Go 标准库已提供足够能力，需要封装说明你没理解标准库用法，或业务逻辑本该下沉 - 所有非导出函数（小写字母开头）应严格限定在当前
package内使用，不要为了“复用”而提升作用域
main.go 是入口，不是业务中枢
很多项目把 main.go 写成大杂烩：初始化 DB、注册路由、加载配置、启动 gRPC、挂 metrics……最后变成不可测、不可复用、无法做集成测试的单点故障。
理想结构是让 main.go 极度轻量，只做三件事：
- 解析命令行参数 / 配置文件
- 构造顶层依赖（DB、Cache、Logger 等）
- 调用某个
app.Run()或server.Start()启动主流程
所有业务初始化逻辑（如 gRPC server 注册 service、HTTP middleware 组装）应下沉到各自 domain 或 cmd 子包中。这样你可以轻松写 app_test.go 来验证整个应用启动链路，而不用起完整服务。
最常被忽略的一点：domain 包之间不能出现 import "myproj/cmd" 或 import "myproj/main" ——那说明职责已经错乱了。
