[!info] related notes

• 所属 MOC: Go 服务工程化 MOC
• 相关概念: Go 包、导入与可见性, Go Modules
• 相关入口: Go Web 与后端 MOC

Go 项目结构与分层

范围

这篇笔记覆盖 Go 项目进入真实服务开发后最常见的结构问题：

• 包怎么拆
• 依赖怎么流动
• 请求层、业务层、数据访问层怎么分

为什么要放在一起理解

很多人找 Go 项目结构时，第一反应是去背一个目录模板。但目录名本身不是核心，真正关键的是：

• 哪些代码应该放在一起
• 哪些依赖方向不能反过来
• 哪些变化应该被边界挡住

关系与依赖

一个比较稳的理解方式是：

1. 先用包表达近邻职责
2. 再用分层表达依赖方向
3. 最后再决定目录长什么样

常见层次可以粗分为：

• 接口层：HTTP / RPC / CLI 输入输出
• 应用层：用例编排
• 领域层：核心业务规则
• 基础设施层：数据库、外部服务、缓存、消息队列

对比与易混淆点

• 好结构不等于目录越多越高级
• internal/、pkg/ 之类目录只是手段，不是答案本身
• 小项目先保持清晰简单，远比过度预埋架构更重要

一条实用原则

先问“变化会从哪里进来”，再设计边界。Go 的包系统很适合做这种保守而清晰的分层。