go build 必须带 -o 参数指定输出路径，否则默认生成同名文件且不覆盖旧版；静态编译需设 cgo_enabled=0 并配合 goos/goarch；务必确保 go.mod 存在、go111module=on 且已执行 go mod tidy。
go build 命令必须带 -o 参数才能控制输出位置
不加 -o 时，go build 默认在当前目录生成同名可执行文件（如 main.go → main），但不会自动覆盖旧文件；若当前目录已有同名二进制，且你没注意，后续运行的可能是旧版本。
更关键的是：不指定 -o 会导致构建产物散落各处，CI/CD 脚本容易误读路径。正确做法是显式声明目标路径：
-
go build -o ./bin/myapp ./cmd/myapp（推荐：明确入口包路径） -
go build -o ./bin/myapp .（仅适用于项目根目录含main.go） - 避免
go build（无参数）——它只在当前目录生成临时可执行文件，不便于分发
交叉编译需同时设 GOOS 和 GOARCH，CGO_ENABLED=0 是默认安全选项
Go 静态编译的核心在于禁用 CGO，否则二进制会依赖目标系统上的 libc 等动态库，导致“本地能跑，线上报 no such file or directory”。
生产部署最常用组合是 Linux AMD64：
CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o ./bin/myapp .-
-s -w去除符号表和调试信息，减小体积约 30–50%，不影响功能 - 若项目用到 SQLite、OpenSSL 等需 CGO 的库，必须保留
CGO_ENABLED=1，并确保目标环境安装对应 dev 包（如libsqlite3-dev）
go.mod 文件缺失或 GO111MODULE=off 会导致依赖解析失败
常见错误现象：go build 报错 cannot find module providing package xxx，或悄悄 fallback 到 GOPATH 模式拉取旧版依赖。
确认三点：
- 项目根目录存在
go.mod（由go mod init生成，非手动创建） -
go env GO111MODULE输出为on或空值（Go 1.16+ 默认开启） - 执行
go mod tidy后，go.sum已更新，且无require行末尾带// indirect却未被实际引用的情况
构建命令中不要混用 go run 和 go build 的语义
go run main.go 是开发调试快捷方式，但它每次都会重新编译并运行，不生成持久化二进制；而 go build 是交付前提。两者不可互换使用。
容易踩的坑：
- 在 CI 脚本里写
go run main.go &启动服务 —— 进程随 shell 退出而终止，且无法做健康检查 - 用
go run测试完就直接打包整个源码目录上线 —— 忘了go build才是生成交付物的唯一方式 - 在多模块项目中（如含
cmd/、internal/），对子目录执行go run *.go可能因导入路径混乱而编译失败
真正交付前，唯一可信的构建动作就是 go build 加完整参数组合。任何省略 -o、忽略 CGO_ENABLED、绕过 go mod tidy 的步骤，都会让“本地能跑”变成线上故障的伏笔。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
