Golang项目目录结构如何组织_Golang项目结构教程【核心】

main.go 应放在 cmd/ 子目录下（如 cmd/myapp/main.go），根目录仅保留 go.mod 等元信息；internal/ 是 Go 强制的访问边界，用于封装不对外承诺的实现；API 层负责错误映射为 HTTP 状态码，domain 层只定义业务语义错误；go.mod 的 module 名应为最终导入路径（如 github.com/user/repo）。main.go 放哪？别放根目录Go 项目启动入口 main.go 必须在 main 包里，但不意味着它该躺在项目最外层。根目录堆 main.go + 几个 .go 文件，很快就会变成"不知道谁依赖谁"的泥潭。实操建议：为每个可执行程序单独建子目录，比如 cmd/myapp/，里面放 main.go 和它的直接依赖（如 CLI 参数解析）cmd/ 下可并列多个命令，例如 cmd/myapp/ 和 cmd/myapp-worker/，对应不同二进制产出根目录只保留 go.mod、README.md、.gitignore 等元信息，不放业务逻辑internal/ 不是摆设，是包可见性的安全线Go 没有 private 包关键字，internal/ 是唯一被 Go 工具链强制约束的访问边界：只有父目录及祖先目录下的包能 import internal/xxx。很多人把它当普通文件夹用，结果外部模块意外依赖了本该封闭的实现细节。常见错误现象：立即学习"go语言免费学习笔记（深入）"；第三方库尝试 import "myproject/internal/handler" 报错 use of internal package not allowed测试文件放在 internal/ 外却想测内部函数，只能暴露不该导出的标识符实操建议：把真正不对外承诺的实现（如数据库连接池封装、中间件内部状态管理）全塞进 internal/pkg/ 用于放**稳定、有明确接口、允许外部依赖**的公共能力，比如通用校验器 pkg/validator别为了省事把 internal/ 建成 internal/common 或 internal/utils ------ 这类命名往往意味着职责模糊、越界风险高API 层和 domain 层怎么分？从 error 类型开始切很多 Go 项目一上来就分 handler、service、repository，但没想清楚分层依据。最实际的切入点是错误处理：HTTP handler 需要返回 400 Bad Request，domain 层只该关心"库存不足"这种业务语义，不该知道 HTTP 状态码。 Mokker AI AI产品图添加背景