go build默认仅构建含func main()的main包，静默失败常见于当前目录非main包、路径错误、cgo依赖未处理、vendor未启用或交叉编译变量缺失。
go build 命令的基本用法和常见失败原因
直接运行 go build 就能生成可执行文件，但多数时候它会静默失败——不是报错，而是不输出任何文件。根本原因是：Go 只对当前目录下包含 func main() 的 main 包进行构建；如果当前是库包（比如 package utils），go build 什么也不会做，也不提示。
实操建议：
- 确认当前目录下有
main.go且首行是package main，且含func main() - 想构建其他目录的主包，用
go build ./cmd/myapp（路径指向含main包的目录） - 构建后默认生成同名二进制（如目录名
myapp→ 输出myapp），Windows 下自动加.exe后缀 - 若提示
no Go files in ...，检查是否误在vendor/或internal/子目录里执行了命令
交叉编译时必须显式设置 GOOS 和 GOARCH
Go 默认按当前系统构建，想生成 Linux 二进制却在 macOS 上执行 go build，结果仍是 macOS 可执行文件——不会报错，但运行失败。交叉编译不是“自动适配”，而是完全依赖环境变量控制。
实操建议：
- 生成 Linux 64 位程序：
GOOS=linux GOARCH=amd64 go build -o myapp-linux - 生成 Windows 64 位：
GOOS=windows GOARCH=amd64 go build -o myapp.exe -
GOARM=7仅对GOARCH=arm有效；GOARCH=arm64时忽略GOARM - 注意 shell 差异：Windows cmd 中用
set GOOS=linux && set GOARCH=amd64 && go build，PowerShell 则用$env:GOOS="linux"
构建时禁用 cgo 以避免动态链接问题
默认启用 cgo 会导致生成的二进制依赖系统 libc（如 glibc），在 Alpine 容器或旧版 Linux 上直接报错 no such file or directory，错误信息里不提 libc，只显示找不到动态链接器路径。
实操建议：
- 彻底静态链接：构建前设
CGO_ENABLED=0，例如CGO_ENABLED=0 go build -a -ldflags '-s -w' -o myapp -
-a强制重新编译所有依赖（含标准库），确保无残留 cgo 调用 -
-ldflags '-s -w'去除调试信息和符号表，减小体积（但会丢失 panic 时的行号） - 若代码中用了
net包的 DNS 解析，默认会回退到 cgo；加GODEBUG=netdns=go强制纯 Go 解析器
模块模式下 vendor 目录不自动生效
即使项目有 vendor/ 目录，go build 默认仍走 module proxy（GOPROXY）下载依赖，除非明确开启 vendor 模式。这导致本地修改 vendor 内代码后构建结果不变，让人误以为修改没生效。
实操建议：
- 启用 vendor 构建：加
-mod=vendor参数，即go build -mod=vendor - 验证是否真走了 vendor：构建时加
-x查看实际编译的 .a 文件路径，应含/vendor/ - 若提示
vendor directory not found，说明go mod vendor没执行过，或go.mod未启用 module（检查是否有go 1.16或更高版本声明） - CI 环境中建议统一用
go build -mod=readonly防止意外写入go.sum
构建看似简单，但 Go 的隐式行为多（比如默认不读 vendor、cgo 开关不显眼、跨平台变量易被 shell 缓存），出问题时往往不是语法错，而是环境状态和预期不一致。动手前先 go env | grep -E 'GOOS|GOARCH|CGO_ENABLED' 看一眼当前真实配置。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
