Go项目构建核心命令是go build，它不依赖外部工具、不生成中间文件、默认只输出可执行二进制，但不编译子目录、不自动定位main包、不打包依赖。
Go 项目构建的核心命令是 go build，它不依赖外部构建工具、不生成中间文件、默认只输出可执行二进制——但你得清楚它默认不编译子目录、不自动处理 main 包位置、也不打包依赖。
什么时候该用 go build 而不是 go run
当你需要生成可分发的二进制（比如部署到没装 Go 的服务器），或者要检查跨平台编译能力时，必须用 go build。go run 只是临时运行，不产出文件，也无法设置 -ldflags 注入版本信息或符号表。
- 调试阶段用
go run main.go更快；发布前务必切回go build -
go build默认只构建当前目录下有main函数的包，不会递归扫描子目录 - 如果项目含多个
main包（如 CLI 工具 + 后台服务），需显式指定路径：go build cmd/cli/main.go
go build 的关键参数与常见陷阱
最常踩的坑是忽略工作目录和模块根目录的关系。Go 1.16+ 强制启用 module 模式，go build 会从当前路径向上查找 go.mod，找不到就报 no Go files in current directory，哪怕你有 main.go。
-
-o指定输出名：go build -o myapp ./cmd/server—— 路径必须指向含main包的目录或文件 -
-mod=readonly防止意外修改go.mod，CI 环境建议加上 - 交叉编译：设
GOOS=linux GOARCH=arm64 go build -o myapp-linux-arm64 .，注意目标系统是否支持 CGO - 禁用 CGO：
CGO_ENABLED=0 go build，否则 Linux 上编译的二进制可能在 Alpine 容器里因缺失libc启动失败
构建多模块项目时的路径逻辑
如果你的仓库里有 api/、cli/、internal/ 多个模块，go build 不会自动识别它们为独立构建单元。它只认 go.mod 所在目录为 module root，子目录只有被显式引用时才参与构建。
- 每个子命令应有自己的
go.mod（不推荐）或统一放在根go.mod下，用./cmd/cli这样的相对路径调用 -
go build ./...会尝试构建所有子目录下的main包，但容易因某个子目录缺少main报错，慎用 - 想批量构建多个
main包？写个简单 shell 循环：for d in cmd/*; do go build -o bin/$(basename $d) $d; done
真正麻烦的从来不是命令本身，而是 go build 对目录结构、module 边界和 CGO 的隐式依赖——这些细节不报错，但会让二进制在目标环境静默失败。
