main.go 应仅初始化配置、构建依赖、调用 app.Run()；业务逻辑拆至 internal/ 下按 handler/service/repo/model 分层；config 和 DB 初始化需抽离为可测试函数，避免硬编码与 init()；go mod tidy 问题需规范 module 路径与 replace 规则。
main.go 里别塞业务逻辑
刚写 Go 的人常把所有代码堆在 main.go 里，HTTP 路由、数据库操作、结构体定义全挤在一起。这会导致：改个接口要翻 300 行、单元测试没法写、别人接手像读天书。
正确做法是让 main.go 只做三件事：初始化配置、构建依赖（比如 DB 实例、Router）、调用 app.Run() 启动服务。其他全拆出去。
-
cmd/yourapp/main.go—— 纯入口，不 import 业务包 - 业务逻辑放到
internal/下，例如internal/user/、internal/order/ - 对外暴露的类型或接口可放
pkg/，比如pkg/httpx封装通用 HTTP 工具
internal 目录不是摆设，得按职责分层
internal/ 是 Go 官方推荐的私有包存放位置，但很多人只建一层目录，然后把 handler、service、model 全塞进去，结果还是耦合严重。
建议每个业务域（如 user）内部再分层，且明确各层边界：
立即学习“go语言免费学习笔记（深入）”；
-
internal/user/handler.go—— 只处理 HTTP 请求/响应，不做校验和业务判断，只调service -
internal/user/service.go—— 实现核心业务逻辑，比如“注册时检查邮箱是否已存在”，它依赖repo -
internal/user/repo.go—— 只负责数据存取，接收user.User结构体，返回error或nil，不碰 HTTP 或 JSON -
internal/user/model.go—— 定义领域结构体，字段名用UserID而非user_id，避免和数据库字段强绑定
这种分法能让单元测试聚焦在 service 层，用 mock repo 快速验证逻辑，不用启 DB。
config 和 database 初始化别写死在 main 里
硬编码数据库地址、超时时间、日志等级，会让项目无法适应开发/测试/生产环境。更糟的是，有人把 sql.Open 放在 init() 函数里，导致测试时 DB 连接提前建立、难以控制生命周期。
应该把配置和资源初始化抽成独立函数，并支持传参控制行为：
- 用
config.Load()从config.yaml或环境变量加载，返回结构体，不要用全局变量存 -
database.NewDB(cfg *config.DBConfig) (*sql.DB, error)—— 返回连接池实例，由调用方决定何时 Close - 在
main()中统一调用这些函数，把返回值注入到 handler 或 service 构造函数中（即依赖注入）
这样测试时可以直接传入内存数据库（如 sqlite://:memory:），或者用 sqlmock 拦截查询。
go mod tidy 后发现 vendor 里多了不该有的包？检查 replace 和 indirect
项目一拆多包，go mod tidy 常会把 internal/ 下的子模块当成外部依赖处理，甚至引入重复版本的 golang.org/x/net，导致编译失败或运行时 panic。
关键点在于模块路径声明和 replace 规则：
- 确保
go.mod第一行是module your-project-name，不是module internal/user这类子路径 - 如果本地有未发布的公共工具包（如
pkg/httpx），用replace your-project-name/pkg/httpx => ./pkg/httpx显式指向本地路径 - 定期检查
go list -m -u all，看哪些包标了(indirect)却被误用；删掉无用的_导入或未调用的包引用
模块路径错一位、replace 少写一个 ./，都可能让 Go 工具链拉错版本——这不是玄学，是路径解析规则严格导致的。
