Go自动同步需绕开os.Copy全量覆盖，应逐文件判断“要不要传”而非“传不传”，避免改一行代码就重传整个二进制或日志文件导致带宽和磁盘IO打满。
Go 自动同步必须绕开 os.Copy 全量覆盖
直接用 os.Copy 同步每个文件，等于每次改一行代码都重传整个二进制或日志文件——带宽和磁盘 IO 都会迅速打满。真实场景下，你得判断「要不要传」，而不是「传不传」。
- 小文件（os.Stat().Size() 和
ModTime()，两者一致就跳过 - 大文件（≥1MB）：额外加双端哈希（前 8KB + 后 8KB 的
sha256.Sum256），不一致再全量校验 - Windows 下注意
ModTime()实际精度只有 100ms，NFS 挂载卷更可能滞后，单靠时间戳必然误同步 - 遇到
syscall.ENOENT或os.ErrNotExist直接 skip，别 panic —— 临时文件、编辑器 swp 文件很常见
用 fsnotify 监控变化但必须防抖+路径过滤
fsnotify 默认对每个写入事件都触发，而 VS Code、GoLand 写文件时会先生成临时文件再 rename，导致同一修改被当成 Create + Write + Rename 三次事件处理。不加控制，同步逻辑会重复执行甚至冲突。
- 对每个文件路径维护一个 lastProcessed 时间戳，100ms 内重复事件直接丢弃
- 监听前用
fs.WalkDir预加载当前有效路径列表，只对已知路径注册监听，跳过.git、node_modules、bin/等目录 - 遇到
Rename事件，先检查是否是.tmp→main.go这类编辑器行为，等待对应Remove或超时后统一按“内容变更”处理 - 别用
strings.HasSuffix(path, ".tmp")过滤临时文件 —— Windows 路径分隔符是\，应改用path.Match("*.tmp")
SFTP 同步需手动处理元数据与原子写入
标准 golang.org/x/crypto/ssh 的 sftp.Client 不保留权限、符号链接、所有者信息，也不支持原子替换。如果目标是 Linux 存储集群，忽略这些会导致服务启动失败或权限错误。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 同步前调用
os.Lstat获取源文件完整 mode，若含os.ModeSymlink，则用os.Readlink+sftp.Symlink - 写入目标文件时，先上传到同级临时路径（如
/data/app/main.go.new），写完再sftp.Rename替换原文件 —— 这是唯一跨文件系统也安全的原子方案 -
sftp.Chmod必须显式调用，否则默认权限是 0644；sftp.Chown在非 root 用户下必失败，应忽略错误而非中断流程 - 遇到
sftp.ErrSshFxPermissionDenied别硬 retry，先确认远程目录是否挂载为 noexec 或只读
并发上传要限流且 buffer 复用
开 100 个 goroutine 同时上传，很容易把 SFTP 连接打爆或触发远端限速策略，尤其在千级小文件场景下，连接建立开销反而超过传输本身。
立即学习“go语言免费学习笔记（深入）”；
- 用
semaphore.NewWeighted(3)控制并发连接数，3 是实测在多数集群上稳定吞吐的上限 - 每个上传 goroutine 内部用
io.Copy，别用io.CopyN—— 若文件被截断，CopyN返回io.ErrUnexpectedEOF中断，而Copy配合io.LimitReader(src, size)能自然终止并返回0, nil - buffer 复用收益有限：实测 64KB
sync.Pool在千级小文件场景仅提升 12% 吞吐，但增加复杂度；建议先用io.Copy默认 32KB buffer，压测瓶颈再优化
