goos/goarch交叉编译总生成本地平台二进制是因为go run不支持交叉编译，仅go build读取这两个变量；必须在同一行显式设置如goos=linux goarch=arm64 go build -o app-arm64 ./cmd/server，并配合cgo_enabled=0禁用cgo，否则易失败。
GOOS/GOARCH交叉编译为什么总生成本地平台二进制
因为go run根本不支持交叉编译，它永远只在当前平台构建并运行；真正生效的是go build配合环境变量。常见错误包括：在命令前漏写GOOS=linux GOARCH=amd64，或把变量设在另一个shell会话里却执行了没带变量的go build。
-
go build才读取GOOS/GOARCH，go run无视它们 - 必须在同一行导出变量：
GOOS=linux GOARCH=arm64 go build -o app-arm64 ./cmd/server - 若项目含
cgo，默认会失败——加CGO_ENABLED=0禁用C依赖，否则需安装对应平台的交叉编译工具链 - 验证是否生效：用
file app-linux-amd64检查输出文件类型，不是“Mach-O”就是对的
os/exec调用docker-compose或ssh时卡死或静默失败
根本原因常是管道缓冲区满（stdout/stderr未消费）或超时无控制。比如cmd.Output()会等命令彻底退出并读完全部输出，但docker-compose up -d启动后立即返回，后台容器还在初始化，这时Output()反而可能阻塞等待日志流结束。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 永远显式设置
cmd.Stdout和cmd.Stderr，哪怕指向io.Discard - 用
cmd.Run()而非cmd.Output()，避免内存堆积和阻塞 - 必须用
exec.CommandContext(ctx, ...)配context.WithTimeout，否则网络故障或服务未响应时脚本永久挂起 - 检查
cmd.Dir是否正确——docker-compose需要cmd.Dir指向docker-compose.yml所在目录，否则报.env file not found
Makefile里管理多平台构建容易漏掉clean和ldflags
Makefile写得看似完整，但实际CI流水线跑起来常因残留文件或调试信息导致体积膨胀、启动慢甚至安全风险。很多团队只写了build-linux目标，却没处理上一次构建的旧二进制，也没压缩符号表。
- 每个构建目标前加
rm -f $(BIN_NAME)-$(GOOS)-$(GOARCH)，防止误传旧文件 - 统一加
-ldflags="-s -w"：去掉符号表和调试信息，二进制体积通常减少30%以上 - 版本信息要注入：用
-ldflags="-X main.Version=$(VERSION) -X main.Commit=$(COMMIT)"，避免运行时查git - 不要用
$(shell git rev-parse HEAD)这种写法——Makefile每次重读都会触发git，应提前在CI中算好传入
embed内嵌配置后热更新失效还找不到原因
//go:embed是编译期行为，不是运行时加载器。你改了config.yaml文件，只要没重新go build，程序永远读的是上次编译打进二进制里的旧内容。这个问题在本地开发时尤其隐蔽，因为IDE可能自动刷新，但生产环境部署后就暴露了。
-
embed只适用于**不变的静态资源**，比如HTML模板、SQL迁移脚本 - 配置类文件必须外置：通过
-config /etc/myapp/config.yaml命令行参数或环境变量指定路径 - 若坚持用embed做兜底，需在代码里判断文件是否存在，不存在才fallback到embed内容
- CI打包阶段别把
config.yaml打进镜像——它应该由K8s ConfigMap或宿主机挂载提供
actions/setup-go@v4），并始终用go mod download预拉依赖，而不是依赖go build顺带下载——后者在离线或限速环境中极易中断。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
