go build生成可执行文件需满足模块初始化、入口识别、依赖解析三条件；默认仅在含main.go目录构建，不写入$gobin，跨平台编译须设cgo_enabled=0并指定goos/goarch。
Go 项目构建不是“编译一下就完事”，而是由 go build、模块系统、平台目标和构建环境共同决定的最终产物形态。能否生成可部署的二进制，关键看是否满足模块初始化、入口识别、依赖解析这三步。
go build 命令的基本用法与常见误用
go build 默认只在当前目录查找 main 包并生成同名可执行文件，不自动写入 $GOBIN，也不会安装到系统路径。很多人卡在这一步，是因为没意识到它对目录结构有隐式要求。
- 必须在包含
main.go的目录下运行（或显式指定go build cmd/myapp/main.go） - 若项目使用标准布局（如
cmd/myapp/main.go），直接在项目根目录运行go build ./cmd/myapp才能正确解析导入路径 - 错误示例：
go build main.go在非main包目录下会报no Go files in ...；在多包目录下可能漏掉依赖子包 - 加
-v参数能看到实际编译了哪些包，排查“为什么没更新”时很实用
GOOS/GOARCH 交叉编译必须关掉 CGO
跨平台构建（比如 macOS 上编译 Linux 二进制）默认会启用 cgo，一旦依赖 C 库（如 DNS 解析、系统调用封装），就会失败或产生动态链接依赖——这违背 Go 静态编译的初衷。
- 安全做法：始终加上
CGO_ENABLED=0，例如CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -o app ./cmd/myapp - 例外情况：仅当你明确需要
cgo功能（如调用 OpenSSL、sqlite3）且已配置好对应平台的 C 工具链时才开启 - 注意：
GOOS=windows下即使关掉cgo，生成的二进制仍带.exe后缀，无需手动添加
go.mod 是构建可信性的前提
没有 go.mod 的项目，go build 会退化为 GOPATH 模式，无法锁定依赖版本，也无法读取 buildinfo 中的模块路径、校验和等关键元数据。
- 初始化模块：在项目根目录运行
go mod init github.com/yourname/project，路径必须是真实可导入的 URL 形式 - 依赖自动发现：首次
go build会触发go mod tidy行为（如果未禁用），但建议显式运行一次以确保go.sum同步 - 构建信息缺失：非模块模式构建的二进制，用
debug.ReadBuildInfo()只能拿到GoVersion和空Path/Version，无法用于供应链审计
构建产物体积与调试信息取舍
生产环境二进制默认包含 DWARF 调试符号，既增大体积又暴露函数名和源码路径。是否剥离，取决于你是否接受用 pprof 或 delve 远程调试。
- 减小体积：加
-ldflags="-s -w"，其中-s去除符号表，-w去除 DWARF 信息 - 保留部分调试能力：只加
-ldflags="-s"，保留 DWARF，方便pprof分析堆栈但隐藏源码路径 - 注意：
-w会禁用runtime/debug.Stack()中的文件行号，线上排障时需权衡
真正容易被忽略的是：构建命令本身不是黑盒，它的行为直接受 go env 输出影响——尤其是 GOPROXY、GOSUMDB 和 GO111MODULE。CI 流水线中一个未显式设置的 GO111MODULE=off 就能让整个依赖解析逻辑降级，导致本地能过、线上构建失败。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
