本文详解 go 官方推荐的代码组织方式，说明为何不应在仓库根目录下自建 `src` 或 `test` 子目录，并指导如何正确布局项目、命名可执行文件及运行构建命令。
Go 并非“允许任意目录结构”的通用脚本语言，而是一门将工程约定深度融入工具链（go build、go test、go install）的语言。其设计哲学强调一致性优于灵活性——这意味着开发者应优先遵循 Go 的标准布局，而非强行适配其他语言的习惯。
✅ 正确的 Go 项目结构
Go 工具链默认以 $GOPATH/src（或 Go 1.11+ 的模块模式下以 go.mod 所在目录为根）为源码起点，且要求每个包路径严格对应文件系统路径。因此，你的项目应直接置于 GOPATH/src/github.com/user/my_project/ 下，无需额外嵌套 src 或 test 目录：
$GOPATH/src/github.com/user/my_project/ ├── go.mod # （推荐启用 Go Modules） ├── main.go # package main ├── some_func.go # package main 或 package myproject（若拆分包） ├── main_test.go # 对应 main.go 的测试，package main ├── some_func_test.go # 对应 some_func.go 的测试 ├── doc/ │ └── README.md
? 注意：Go 没有“全局 test 目录”概念。测试文件必须与被测源文件位于同一包目录下，且以 _test.go 结尾。go test ./... 会自动发现并运行所有匹配的测试。
? 构建与安装：命名与路径控制
-
从项目根目录构建：只要你在 my_project/ 目录下（即 go.mod 或 main.go 所在目录），直接运行即可：
cd $GOPATH/src/github.com/user/my_project go build # 生成可执行文件：./my_project（基于目录名自动推导） go install # 安装到 $GOPATH/bin/my_project（名称由当前目录名决定）
-
自定义可执行文件名：Go 不提供 --output-name 参数，但可通过以下任一方式控制：
- ✅ 推荐：重命名项目目录（如 mv my_project myapp），则 go build 输出 ./myapp；
- ✅ 灵活：使用 -o 显式指定输出路径：
go build -o ./bin/myapp .
⚠️ 为什么避免自建 src/ 和 test/ 目录？
-
若强制采用 my_project/src/main.go，Go 会将其解析为包路径 github.com/user/my_project/src，导致：
- import "github.com/user/my_project" 失败（实际路径不匹配）；
- go install 生成二进制名为 src（因目录名覆盖包名逻辑）；
- 第三方工具（如 gopls、go list）无法正确识别模块边界；
- CI/CD 流程中依赖解析失败。
Go 的测试机制依赖文件共置：some_func_test.go 必须与 some_func.go 同目录，否则 go test 无法关联被测逻辑，也无法访问未导出标识符（如 func helper()）。
? 总结与最佳实践
| 场景 | 推荐做法 | 错误示例 |
|---|---|---|
| 项目根目录 | go.mod + main.go + 功能文件直接平铺 | 在仓库根新建 src/ 包裹全部代码 |
| 测试文件位置 | xxx_test.go 与 xxx.go 同目录 | 统一移入 test/ 目录 |
| 可执行文件命名 | 依赖目录名，或用 -o 指定 | 试图通过 go install -name=myapp（不存在该 flag） |
| 模块管理 | Go 1.11+ 强烈建议启用 go mod init github.com/user/my_project | 仅依赖旧式 GOPATH，忽略模块化优势 |
遵循 Go 的约定不是妥协，而是解锁其工具链全部能力的前提。当你习惯 go run .、go test ./...、go list -f '{{.Name}}' ./... 的流畅体验后，便会理解：Go 的“强制”恰恰是其工程效率的基石。
