上线部署需用 exec.Command 配合超时控制、错误传播、日志上下文和环境隔离；配置须通过环境变量注入，敏感信息严禁硬编码；流程应拆分为幂等函数并添加资源清理。
直接用 go build 加 exec.Command 就能跑通基础部署，但真要上线用，必须处理超时、错误传播、日志上下文和环境隔离——否则一次 git clone 超时或 scp 权限失败，脚本就静默卡死，你得连服务器手动查。
用 exec.Command 调外部命令，但别裸调
Go 标准库的 exec.Command 是核心，但直接 cmd.Run() 会丢失输出、掩盖错误原因。常见坑是：命令卡住没超时、stderr 混在 stdout 里、退出码非 0 却没 panic。
- 始终设置
cmd.Stdout和cmd.Stderr到os.Stdout或缓冲区，调试时能立刻看到哪步挂了 - 用
cmd.CombinedOutput()获取完整输出，再根据err类型判断是执行失败还是命令自身报错 - 加超时：用
context.WithTimeout(ctx, 30*time.Second)包裹cmd.Start()和cmd.Wait() - 别信
os/exec的默认行为——PATH在不同环境可能不一致，显式传入env := append(os.Environ(), "PATH=/usr/local/bin:/usr/bin")
配置不能硬编码，环境变量优先
目标主机、端口、镜像仓库地址这些，写死在代码里等于给 CI/CD 埋雷。CI 流水线里改个 IP 就得 recompile，还容易误提交密钥。
- 所有敏感项（SSH 密钥路径、token、密码）只从
os.Getenv("SSH_KEY_PATH")读，绝不写进代码或 YAML - 非敏感配置如
DEPLOY_ENV=staging、APP_NAME=myapi也走环境变量，本地开发用.env+godotenv加载，CI 直接注入 - 如果必须用配置文件，用
viper支持多格式（YAML/JSON/ENV），但注意viper.ReadInConfig()失败时不会 panic，要主动检查viper.ConfigFileUsed()
部署流程拆成函数，每个函数只做一件事
把 “构建 → 推镜像 → 拉取 → 重启” 写在一个 main 函数里，等于放弃可测试性和可复现性。线上出问题时，你没法单独重试“推镜像”这步。
- 拆成
BuildBinary()、PushDockerImage()、SSHRunCommand()等独立函数，每个函数接收明确参数、返回 error - 给每个函数加
defer log.Printf("start %s", "BuildBinary")和结束日志，方便定位卡点 - 关键步骤加幂等判断：比如
BuildBinary()先检查./build/app是否存在且 mtime 新于main.go，避免无谓 rebuild - 远程操作前先
SSHRunCommand("ls -l /opt/myapp")验证连通性，别等到systemctl restart才发现权限不对
交叉编译和 CGO_ENABLED 容易被忽略的细节
GOOS=linux GOARCH=amd64 go build 看似简单，但生产环境一跑就 DNS 解析失败，十有八九是 CGO_ENABLED=0 搞的鬼。
-
CGO_ENABLED=0生成纯静态二进制，适合容器部署，但它会让net包 fallback 到 Go 自研 DNS 解析器，该解析器不读/etc/resolv.conf，只支持127.0.0.11（Docker 默认）或硬编码 nameserver - 若服务要访问 etcd、Prometheus 或私有 DNS，要么关掉
CGO_ENABLED并确保容器网络可用，要么保留CGO_ENABLED=1并在镜像里装libc（如debian:slim） - 交叉编译时，
GOOS和GOARCH必须和目标服务器完全一致；ARM64 机器上跑GOARCH=arm64，别写成aarch64
最常漏掉的是服务退出时的资源清理：SSH 连接没 defer client.Close()，临时文件没 os.RemoveAll，长连接没设 KeepAlive。这些不会让脚本当场失败，但积压几天后，目标机 fd 耗尽或磁盘写满，问题才爆发。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
