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 Requestdomain 层只该关心“库存不足”这种业务语义不该知道 HTTP 状态码。 Mokker AI AI产品图添加背景