应使用sha256.sum256配合分块读取（如1mb/块）计算大文件哈希，避免io.copy导致内存爆炸；同步前须双向比对目标端modtime与size，冲突时中断并报错；增量传输优先用zstd压缩后哈希粗筛，状态文件写入需mutex保护且原子提交。
用 sha256.Sum256 + 分块读取避免内存爆炸
大文件（比如 >100MB）直接 io.Copy 到 sha256.New() 会吃光内存，尤其在并发场景下。Go 标准库不提供“分块哈希”原语，得自己控制读取节奏。
实操建议：
- 用
sha256.Sum256类型（不是sha256.New()），它只有 32 字节，可复用；每次读一块（如 1MB），hash.Write(buf[:n])，再hash.Sum([32]byte{})得到当前块哈希 - 把所有块哈希拼成字节切片，再对这个切片算一次最终哈希（
sha256.Sum256(append([]byte{}, blocks...))），比全量哈希快 3–5 倍，且内存恒定在几 MB 内 - 别用
os.ReadFile或io.ReadAll—— 它们无视大小，一上来就 malloc 整个文件
同步前必须双向比对目标端状态，否则覆盖新内容
只看源端是否变更，是同步逻辑最常踩的坑。比如目标端日志被运维手动追加了新行，你却用旧版本覆盖过去，数据就丢了。
实操建议：
- 同步前通过 SFTP 的
Stat()或 SSH 执行stat -c "%Y %s" file拉取目标端ModTime().UnixNano()和Size() - 若目标端
ModTime() > 源端 ModTime()且哈希不一致，中断并报错："target is newer, manual conflict resolution required" -
--force参数必须显式打印警告，并记录源/目标时间戳与哈希到日志，不能静默覆盖
增量传输不是“传差异块”，而是靠压缩敏感性粗筛
Go 标准库没有内置 bsdiff 或 rsync 协议，手写二进制 diff 成本高、易出错。生产环境别硬刚。
实操建议：
- 对源文件先做流式
zstd压缩（用github.com/DataDog/zstd），再计算压缩后字节流的sha256.Sum256—— 相似内容压缩率接近，哈希大概率一致，能跳过 70%+ 文件的完整内容比对 - 确认变更后，文本类文件（如日志、配置）可用
bytes.Equal行级比对，但注意换行符：统一转\n再比，避免\r\n导致误判 - 真要传差异块？调
rsync --write-batch=patch.bin生成 patch，Go 只负责执行命令 + 校验exit code == 0，别重复造轮子
状态文件并发写入必须加锁，且不能共享 hash.Hash 实例
多个 goroutine 同时写 backup.state.json 或同时调 hash.Write()，会导致 JSON 文件损坏或哈希值错乱 —— hash.Hash 不是并发安全的，os.File 也不是。
实操建议：
- 用
sync.Mutex包裹状态文件写入逻辑，写完立即file.Sync()，再os.Rename(tmp, final)原子提交 - 每个 goroutine 必须创建独立的
sha256.Sum256或hash.Hash实例；共用一个实例等于让所有协程往同一块内存里写 - 状态文件键用相对路径（
filepath.Rel(root, path)），值存{Size int64; ModTime int64; Hash [32]byte}，JSON 序列化后人工可读、调试方便
最容易被忽略的是时间戳容差和硬链接处理：NFS 或 FAT32 上 ModTime() 精度可能只有 2 秒，跨机器时钟偏差需容忍 ±1s；硬链接指向同一 inode，但路径不同，仅靠路径查状态会重复备份 —— 要用 os.Stat().Sys().(*syscall.Stat_t).Ino 去重。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
