go build 默认只编译当前目录，因其采用“单包模式”，仅处理当前目录下满足package main的.go文件，不递归扫描子目录；子包需被显式指定路径（如./cmd/app）或通过导入图自动解析，而非文件系统遍历。
go build 为什么只编译当前目录，不自动包含子包？
因为 go build 默认行为是“单包模式”：它只识别当前目录下的 .go 文件，并要求该目录必须是 main 包。子目录哪怕也含 main.go，只要没被显式引用，就完全不会参与编译。
- 常见错误现象：项目结构为
cmd/app/main.go+internal/handler/handler.go，直接在根目录运行go build报错no Go files in ... - 正确做法是明确指定入口包路径：
go build ./cmd/app，Go 会自动递归解析该包依赖的所有子包（包括internal/下的代码） - 如果子包不在标准导入路径下（比如用了相对路径或未声明 module），
go build会静默跳过，不报错也不编译——这是最容易被忽略的坑 - 性能影响：显式指定包路径比通配符（如
./...）更快，后者会扫描整个工作区，可能触发大量无关模块检查
如何让 go build 编译整个工程所有可执行命令？
用 ./... 模式配合 cmd/ 目录约定是最稳妥的方式。前提是项目已初始化 go mod，且每个命令入口都放在独立子目录中并声明为 package main。
- 典型结构：
cmd/api/main.go、cmd/cli/main.go、cmd/admin/main.go - 执行
go build ./cmd/...即可批量编译全部命令，生成api、cli、admin三个可执行文件 - 注意：不能写成
go build ./...—— 这会尝试编译vendor/、testdata/等非代码目录，大概率失败；加cmd/前缀是关键过滤 - Windows 下生成的文件默认带
.exe后缀，Linux/macOS 不带；跨平台时建议统一用-o指定输出名，避免脚本硬编码
GOPATH 和 Go Modules 共存时，go build 优先走哪条路？
Go 1.16+ 默认启用 Modules，go build 会先找当前目录或上层最近的 go.mod 文件；找不到才回落到 GOPATH/src 路径查找。但二者混用极易出问题。
- 容易踩的坑：项目根目录没有
go.mod，但你在$GOPATH/src/example.com/myapp下执行go build，看似能编译，实则依赖解析走的是旧 GOPATH 模式，无法使用go.mod中声明的版本约束 - 验证方式：运行
go env GOMOD，输出非空路径说明走 Modules；输出""（空字符串）说明 fallback 到 GOPATH - 强烈建议：新项目一律在根目录执行
go mod init example.com/myapp，然后删掉GOPATH/src下的旧路径，避免环境变量干扰 - 兼容性提醒：某些 CI 脚本仍硬编码
$GOPATH，若你禁用了 GOPATH，需同步更新脚本中的路径逻辑
编译时提示 “cannot find package” 但明明 import 路径是对的
这不是路径写错了，而是 Go 无法定位该包的物理位置——根本原因通常是模块未下载或代理失效，而不是 import 语句本身有问题。
- 先运行
go list -m all | grep xxx确认依赖是否出现在模块列表里；没出现就说明没拉下来 - 检查
GOPROXY是否生效：go env GOPROXY应输出类似https://goproxy.cn,direct；若为direct或空，国内环境几乎必失败 - 临时修复：执行
go mod download强制下载所有依赖；长期方案是配置代理：go env -w GOPROXY=https://goproxy.cn,direct - 特别注意：如果依赖是私有仓库（如 GitHub Enterprise），
GOPROXY=direct是必须的，但要提前配置好 SSH 或 token 认证，否则go build会在 clone 阶段卡住
go.mod 文件的 commit 状态和 go.sum 的校验一致性。哪怕 go build 成功，如果 go.sum 被手动删改或未提交，协作时其他人拉代码后第一次 build 就可能因校验失败中断——这个点不在命令行报错里，得看 go build 输出末尾是否带 verifying ... 字样。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
