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 实现：
立即学习“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，构建会直接失败。
使用 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 分支；上线前务必在目标环境中实际运行验证，而不是只看构建是否成功。
