go build 命令默认在含 main.go 的目录执行，生成与目录同名的可执行文件（Linux/macOS 无后缀，Windows 为 .exe）；必须确保包为 main 且含 func main()，否则报错；-o 可指定输出路径和文件名。

go build 命令生成可执行文件的基本用法

直接在项目根目录运行 go build 就能生成当前 main 包对应的二进制文件，文件名默认是当前目录名。比如项目在 ~/myapp，执行后会生成名为 myapp 的可执行文件（Linux/macOS）或 myapp.exe（Windows）。

常见错误：在非 main 包目录下执行 go build，报错 no Go files in ... 或 cannot build non-main package。必须确保当前目录包含 main.go 且其中定义了 func main()。

• 指定输出路径和文件名：用 -o 参数，例如 go build -o ./dist/app ./cmd/myapp
• 跨平台构建需显式设置 GOOS 和 GOARCH，如 GOOS=windows GOARCH=amd64 go build -o app.exe .
• 如果项目使用 Go modules，确保 go.mod 存在且 GO111MODULE=on（Go 1.16+ 默认开启）

处理依赖与静态链接：为什么你的二进制一拷就崩

默认情况下，go build 生成的是静态链接的二进制，不依赖系统 libc（除非用了 cgo）。但一旦启用 cgo（比如调用 SQLite、PNG 解码等），就会动态链接 libc，导致在 Alpine 等精简镜像里运行失败，报错类似 no such file or directory 或 standard_init_linux.go:228: exec user process caused: no such file or directory。

解决方法是禁用 cgo 并强制纯 Go 实现：

• 构建前设环境变量：CGO_ENABLED=0 GOOS=linux go build -a -ldflags '-s -w' -o app .
• -a 强制重新编译所有依赖（含标准库），配合 CGO_ENABLED=0 确保无 C 依赖
• -ldflags '-s -w' 去除调试符号和 DWARF 信息，减小体积（-s 去符号表，-w 去调试信息）

构建多平台二进制时常见的环境变量陷阱

很多人以为只要写 GOOS=windows go build 就能生成 Windows 可执行文件，结果在 macOS 上得到一个无法运行的 app 文件——因为没加 .exe 后缀，系统不识别为可执行程序；更严重的是，若本地未安装对应平台的编译工具链（比如 Windows 的 gcc），而项目又启用了 cgo，构建会直接失败。

关键点：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 跨平台构建无需目标系统环境，但 CGO_ENABLED=0 是安全前提；启用 cgo 时，GOOS/GOARCH 必须匹配本地已安装的交叉编译工具链
• Windows 目标务必加 -o app.exe，否则生成的文件名无后缀，双击打不开，命令行也常被 shell 忽略
• ARM64 构建注意：Mac M 系列芯片上 GOARCH=arm64 是默认，但若想构建 x86_64 版本，得显式写 GOARCH=amd64 并确认 Go 安装支持该架构

Makefile 或 CI 中自动化构建的实用建议

手动敲一堆 GOOS=xxx 很容易漏参数或拼错，CI 流水线里更需要稳定可复现的构建过程。不要把构建逻辑散落在多个脚本里，推荐用 Makefile 封装常用组合。

示例片段（适用于 GitHub Actions 或本地 dev）：

build-linux:
	GOOS=linux CGO_ENABLED=0 go build -a -ldflags '-s -w' -o dist/app-linux .

build-windows:
	GOOS=windows CGO_ENABLED=0 go build -a -ldflags '-s -w' -o dist/app.exe .

build-darwin:
	GOOS=darwin CGO_ENABLED=0 go build -a -ldflags '-s -w' -o dist/app-darwin .

注意：CGO_ENABLED=0 应作为默认项写入每个 target，而不是全局 export——避免影响本地开发时的调试体验（比如需要 sqlite3 调试时临时启用 cgo）。

真正麻烦的不是语法，而是不同环境对 cgo 的隐式依赖：某个第三方包看似纯 Go，却在 build tag 里悄悄引入了 cgo 分支；上线前务必在目标环境中实际运行验证，而不是只看构建是否成功。

golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！