当未显式指定包路径时，go build 默认仅构建当前目录下的主包（main package）及其已导入且过时的依赖，不会递归扫描子目录；其行为由 Go 工作区结构和导入图驱动，而非文件系统遍历。
当未显式指定包路径时，`go build` 默认仅构建当前目录下的主包（main package）及其**已导入且过时的依赖**，不会递归扫描子目录；其行为由 go 工作区结构和导入图驱动，而非文件系统遍历。
go build 的构建范围决策高度依赖于 Go 的包模型与依赖图分析，而非简单的目录遍历。它不采用“查找所有含 main.go 的子目录”或“递归搜索 *.go 文件”等启发式策略。核心规则如下：
✅ 默认行为：仅构建当前目录的主包
若在终端中执行 go build 且未提供任何参数（如 go build ./... 或 go build cmd/myapp），Go 工具链会：
- 检查当前工作目录是否为一个有效的 Go 包（即包含 .go 文件且满足包声明规范）；
- 仅构建该目录下的包——若该包是 package main，则生成可执行文件；否则报错 no buildable Go source files；
- 不进入任何子目录，无论其是否包含合法的 Go 包。
$ tree .
.
├── main.go # package main
├── utils/
│ └── helper.go # package utils（不会被构建）
└── internal/
└── db.go # package internal（不会被构建）
$ go build # ✅ 成功：仅编译 ./main.go，生成可执行文件
$ ls -l | grep '^-' | head -1
-rwxr-xr-x 1 user user 2.1M Jun 10 10:30 myapp # 输出名默认为目录名? 依赖构建：按需、增量、图驱动
go build 会自动解析当前包的 import 语句，构建所有直接/间接依赖中已安装但过时的包（即源码修改时间晚于已安装 .a 归档或模块缓存）。此过程：
- 严格基于导入图（import graph），而非文件系统层级；
- 跳过已缓存且未变更的依赖（提升速度）；
- 不构建未被当前包导入的任何子目录包（即使它们语法正确）。
⚠️ 注意：go build -a（强制全部重建）也不会构建未被导入的子目录包。它仅强制重新编译所有已参与构建图的依赖包（包括标准库），而非扩展构建范围。这是常见误解——-a 控制“是否跳过缓存”，而非“是否扩展路径”。
? 显式扩展构建范围的方式
若需构建多个包（如多命令项目），必须显式指定模式： | 命令 | 行为 | |------|------| | go build ./cmd/... | 构建 ./cmd/ 下所有子目录中的 main 包（递归匹配） | | go build ./... | 构建当前模块下所有子目录中的可构建包（含 main 和非 main） | | go build ./api ./cli ./pkg/utils | 明确列出多个包路径 |
✅ 推荐实践：在模块根目录使用 go list ./... 预览将被影响的包，验证路径模式是否符合预期。
? 总结
- go build 的“默认无参”行为是极简主义设计：只处理当前目录，确保可预测性与最小干扰；
- 子目录是否参与构建，完全取决于是否被当前包显式导入，而非物理位置或文件名；
- 想要批量构建，请使用 ./... 等通配模式，并配合 go list 进行调试；
- GOPATH 模式下行为一致，但 Go 1.16+ 默认启用模块模式（go.mod），路径解析以模块根为基准。
理解这一机制，能避免误以为 go build 会“自动发现”子命令，从而写出更可靠、可复现的构建脚本。
