本文详解 go 官方推荐的代码组织方式，指出在项目根目录下额外创建 `src/` 或 `test/` 子目录违背 go 工具链设计原则，并提供符合 gopath（及现代 go modules）规范的标准结构、构建方法与可执行文件命名控制方案。
Go 不是一门“允许任意目录结构”的语言——它的构建系统（go build、go test、go install）深度依赖包路径与文件系统路径的一致性。你提出的问题（如“如何让 go build 在 my_project/ 目录下识别 src/ 中的 main.go”或“如何让生成的二进制名为 my_project 而非 src”），本质上源于对 Go 项目布局约定的偏离。强行绕过这一约定，不仅导致命令失效、产物命名异常，更会引发导入路径错误、测试无法发现、模块解析失败等连锁问题。
✅ 正确的 Go 项目结构（兼容 GOPATH 与 Go Modules）
Go 官方明确建议：源码即包，包即目录。main 包必须位于其最终可执行文件所对应的目标目录中。因此，正确的结构应如下（以 github.com/user/my_project 为例）：
$GOPATH/src/github.com/user/my_project/ # GOPATH 模式（Go 1.11 前） # 或（推荐，Go 1.11+ 启用 Modules 后） ./my_project/ # 任意路径，但需含 go.mod
目录内容为：
my_project/ ├── go.mod # 运行 `go mod init github.com/user/my_project` 生成 ├── main.go # package main，入口文件 ├── some_func.go # package main 或其他逻辑包（如 package myproject） ├── main_test.go # 与 main.go 同目录，package main（或 _test） ├── some_func_test.go ├── doc/ │ └── README.md └── ...
? 关键点：main.go 必须直接位于项目根目录（即模块根目录），而非嵌套在 src/ 或 test/ 下。Go 的 main 包名由其所在目录决定，go build 默认以当前目录为构建起点，并将目录名作为可执行文件默认名称。
? 构建与安装：精准控制输出名称
当你处于 my_project/ 目录时：
- go build → 生成可执行文件 my_project（Linux/macOS）或 my_project.exe（Windows）
- go build -o myapp → 显式指定输出名为 myapp
- go install → 将二进制安装至 $GOBIN（或 $GOPATH/bin），名称仍为 my_project
示例：
cd my_project go mod init github.com/user/my_project # 初始化模块（必需） go build # 输出: ./my_project go build -o bin/myapp # 输出: ./bin/myapp go install # 安装到 $GOBIN/my_project
❌ 为什么不应额外创建 src/ 或 test/ 目录？
- 路径即导入路径：若 main.go 放在 src/main.go，则其完整包路径为 github.com/user/my_project/src，go build 会尝试构建 src 包，生成二进制名为 src，且外部无法正确导入你的业务逻辑（如 import "github.com/user/my_project/some_func" 将失败）。
- 测试发现机制失效：go test 默认扫描当前目录及子目录中 _test.go 文件，但要求测试文件与被测文件同包同目录（或通过 //go:build ignore 等特殊标记）。将测试文件移入独立 test/ 目录会导致 go test 完全忽略它们。
- Modules 兼容性风险：Go Modules 严格依据 go.mod 所在目录确定模块根。嵌套 src/ 会使 go mod tidy、go get 等命令无法准确定位依赖和版本。
✅ 进阶建议：合理组织非主干代码
若需逻辑分层，应使用标准 Go 包结构，而非人工目录隔离：
my_project/ ├── go.mod ├── main.go # import "./cmd" or "./internal/app" ├── cmd/ │ └── my_project/ # 可执行入口（package main），控制 CLI 行为 ├── internal/ │ └── app/ # 核心业务逻辑（package app），仅限本模块使用 ├── pkg/ │ └── utils/ # 可导出工具包（package utils），供外部引用 ├── testdata/ # 测试所需静态数据（非代码，go test 自动忽略） └── ...
此结构既保持 Go 工具链原生支持，又实现清晰职责分离，且完全兼容 go build ./cmd/my_project 等精确构建指令。
总结
Go 的“约定优于配置”不是限制，而是稳定性的保障。放弃在项目内重建 src/ 目录的尝试，拥抱标准布局：模块根目录即代码根目录，main.go 直落其中，测试文件紧邻被测源码。这不仅能解决构建失败与命名异常问题，更能让你无缝接入 Go 生态的测试、文档（go doc）、格式化（gofmt）、静态分析（go vet）等全部工具链。先按标准方式实践一到两个项目，再谨慎评估是否需微调——绝大多数场景，Go 的默认方式就是最优解。
