rsync 是同步远程配置文件的首选，Go 应调用 rsync 而非自行实现文件传输；需显式设置 PATH 和工作目录、捕获 stderr 并解析退出码（如 23 表示部分失败），定时任务应使用系统 cron 而非 time.Ticker。
rsync 是同步远程配置文件的首选，不是 Go 自己读写
Go 语言标准库没有内置可靠的跨机文件同步能力。硬用 os.Open + http.Post 或自己实现 SFTP 上传，会漏掉权限、软链、断点续传、远端清理等关键逻辑。生产环境直接调 rsync 是更稳的选择——Go 只需调度、记录日志、判断失败类型并告警。
常见错误是用 scp 全量覆盖：每次改一个 config.yaml，都把整个目录重传一遍，既慢又占带宽。而 rsync --archive --delete 能自动跳过未变文件，且支持 --partial 断点续传。
- 确保远程服务器已启用 SSH 密钥登录（不用密码），否则
rsync会在 cron 或 systemd 里卡住 - 本地先手动跑通：
rsync -avz --delete ./configs/ user@host:/etc/myapp/，确认路径可写、网络通、权限够 - 若配置文件含敏感信息，避免用
--compress（压缩过程可能泄露内存内容），优先保安全而非省带宽
Go 调用 rsync 必须显式控制环境与工作目录
exec.Command 默认继承当前进程的 PATH 和 cwd，但在 cron、systemd 或容器中，PATH 极简（如只有 /usr/bin），rsync 很可能找不到；相对路径在子进程中也容易错乱。
正确做法是固定环境变量并指定工作目录：
立即学习“go语言免费学习笔记（深入）”；
cmd := exec.Command("rsync", "-avz", "--delete", "./configs/", "user@host:/etc/myapp/")
cmd.Env = []string{"PATH=/usr/bin:/bin"}
cmd.Dir = "/tmp"- 不要用
os.Getenv("PATH")拼接，不同上下文差异太大 -
cmd.Dir设为/tmp这类空目录，避免因当前目录无写权限导致rsync创建临时文件失败 - 所有路径必须是绝对路径，
~/在rsync命令中不展开
只看 err != nil 不足以判断同步是否成功
rsync 的退出码语义丰富：0 表示完全成功；23 表示部分文件失败（如权限不足）；24 表示文件 vanished；这些都会让 cmd.Run() 返回 err != nil，但你可能只收到 *exec.ExitError，而没检查具体退出码。
必须捕获 stderr 并解析退出码：
- 声明
var stderr bytes.Buffer，并设cmd.Stderr = &stderr - 执行后检查：
if exitErr, ok := err.(*exec.ExitError); ok && exitErr.ExitCode() != 0 - 典型需告警的
stderr片段："Permission denied"、"No route to host"、"Connection refused" - 日志里记下完整
stderr.String()，别只存"rsync failed"这种无用信息
定时同步别用 time.Ticker，用系统级 cron
Go 的 time.Ticker 在进程崩溃、OOM、或被 kill 后就停了，无法保证配置按时更新。而系统级 cron 或 systemd timer 具备持久性、重启恢复、日志追踪等能力。
- 写好 Go 脚本后，加执行权限：
chmod +x ./sync-configs - 在
crontab -e中添加：0 * * * * /path/to/sync-configs >> /var/log/config-sync.log 2>&1 - 注意 cron 环境变量极简，所以脚本内部必须像上文那样显式设置
PATH和Dir，不能依赖 shell 配置 - 若需按 Git 分支动态拉取配置，建议在 Go 脚本里先
git pull，再rsync，而不是把 git 逻辑塞进 crontab
最易被忽略的是：rsync 失败时静默吞掉 stderr，或者只检查 err 是否为 nil。实际生产中，23 号退出码（部分失败）比 0 号更常见——比如远端 /etc/myapp 下某个子目录权限是 root:root，普通用户无法写入，但 rsync 仍会返回非零退出码并输出具体路径到 stderr。不捕获它，等于备份形同虚设。
