用os/exec调用SSH/rsync实现部署：需用sh-c包裹远程命令、注意rsync斜杠语义、绕过known_hosts校验需区分环境、状态必须持久化到文件、编译时加-ldflags"-s-w"减小体积、务必检查返回码和远程文件存在性。
用 os/exec 调用 SSH 和 rsync 实现基础部署
Go 本身不内置 SSH 客户端，但通过调用系统命令最直接、最可控。重点不是“封装 SSH 库”，而是避免引入额外依赖和连接状态管理复杂度。
常见错误是直接拼接字符串执行 ssh user@host 'cd /app && git pull'，这在含空格路径、特殊字符或需要交互式环境变量时会失败。
- 用
os/exec.Command("rsync", "-avz", "--delete", "./dist/", "user@host:/var/www/")同步静态资源，比手动 SCP 更可靠 - 远程命令务必用
sh -c包裹，并显式指定 shell 环境：ssh user@host "sh -c 'cd /app && PATH=/usr/local/bin:$PATH ./deploy.sh'" - 注意
rsync的尾部斜杠语义：/src/同步内容，/src同步目录本身
用 golang.org/x/crypto/ssh 手动建连时绕过 known_hosts 检查
自动化场景下，首次连接触发的 known_hosts 交互或校验失败（如服务器重装后 host key 变更）会导致脚本卡住或报错 ssh: handshake failed: knownhosts: key mismatch。
解决方案不是禁用全部验证，而是提供可预测的主机密钥检查逻辑：
立即学习“go语言免费学习笔记（深入）”；
- 设置
HostKeyCallback为ssh.InsecureIgnoreHostKey()仅用于测试环境 - 生产环境应预存可信公钥并比对：
ssh.FixedHostKey([]byte("ssh-rsa AAAA...")) - 连接前可用
ssh-keyscan -H host.example.com提前获取并写入本地known_hosts文件
部署流程状态必须用文件或数据库持久化，不能只靠内存变量
部署脚本意外中断（如网络断开、进程被 kill）后，若只靠内存记录当前步骤，重启即丢失上下文，极易导致重复操作（如重复迁移数据库）或跳过关键步骤（如忘记重启服务）。
最轻量的做法是用单个 JSON 文件记录状态：
{
"stage": "sync_files",
"timestamp": "2024-05-20T14:22:10Z",
"commit_hash": "a1b2c3d"
}
- 每次进入新阶段前，先
ioutil.WriteFile(".deploy-state.json", data, 0644) - 启动时读取该文件，判断是否从中断处恢复，还是全新部署
- 避免用
os.Getwd()或相对路径定位状态文件，统一用flag.String("state-file", "./.deploy-state.json", "")显式传入
构建二进制时用 -ldflags "-s -w" 减小体积并剥离调试信息
部署工具最终要分发到不同运维机器上运行，体积和启动速度直接影响体验。未优化的 Go 二进制常含大量调试符号和反射元数据。
编译命令需明确控制链接器行为：
-
go build -ldflags "-s -w" -o deployer ./cmd/deployer可减少 30%~50% 体积 - 若需支持交叉编译（如 macOS 开发、Linux 部署），加
GOOS=linux GOARCH=amd64，注意cgo依赖可能失效 - 不要用
upx压缩 Go 二进制——多数现代 Go 版本已自带高效压缩，且 UPX 可能触发部分安全扫描误报
真实部署链路里，最难的从来不是“怎么连上服务器”，而是“连上之后怎么知道刚才那步到底成功没”。日志输出、返回码检查、远程文件存在性验证，三者缺一不可。别信 stdout 里那句 “Done.”。
