增量备份的核心逻辑是“时间戳+状态快照”，需结合os.stat的modtime与上次备份记录比对，并推荐辅以sha256校验和判断真实变更，避免仅依赖文件大小或名称导致漏备。
增量备份的核心逻辑不是“差量文件”，而是“时间戳+状态快照”
Go 本身不提供内置的增量备份机制，必须靠开发者定义“什么是变化”。最可靠的方式是结合 os.Stat 获取文件修改时间（ModTime）与上一次备份记录中的时间戳比对；更健壮的做法是配合校验和（如 sha256.Sum256）判断内容是否真有变更。单纯依赖文件大小或名称容易漏掉静默修改（比如日志轮转后同名覆盖）。
实操建议：
- 每次完整备份后，将所有已备份文件的
ModTime和Sum256写入一个轻量元数据文件（如backup.manifest.json），用encoding/json序列化 - 增量备份时，遍历目标目录，对每个文件调用
os.Stat，跳过未修改（ModTime≤ 上次记录 && 校验和一致）的条目 - 避免用
filepath.Walk直接处理符号链接——默认会跟随，可能造成循环或越界，应设filepath.WalkDir+ 自定义fs.DirEntry判断IsDir和Type().IsRegular()
用 archive/tar 打包时必须控制文件路径安全，否则恢复会写到任意位置
Go 的 archive/tar 不做路径净化，如果源路径含 ../ 或绝对路径，tar.Header.Name 会原样保留，解压时可能覆盖系统关键文件。这不是 bug，是设计使然——库不替你做安全决策。
实操建议：
- 在写入
tar.Writer前，对每个文件路径调用filepath.Clean，再检查是否以..开头或包含..路径段 - 更稳妥的做法是用
filepath.Rel计算相对于备份根目录的相对路径，确保Header.Name始终是干净的相对路径 - 恢复时，不要直接用
Header.Name拼接目标路径，而应先filepath.Join(restoreRoot, header.Name)，再用strings.HasPrefix检查结果是否仍在restoreRoot内部
恢复过程要区分“覆盖”和“跳过已存在文件”，且需保留原始权限和时间戳
增量恢复不是简单解压：用户常需要“只恢复上次备份后新增或变更的文件”，但又不想误删本地手动添加的配置。同时，os.FileMode 和 os.Chtimes 必须显式调用，否则新建文件会丢失原始 ModTime 和执行位等属性。
实操建议：
- 恢复前读取当前目录下文件的
os.Stat，与 tar 包内Header中的ModTime和Mode()对比，决定是否覆盖 - 创建文件后立即调用
os.Chmod(f, header.FileInfo().Mode())和os.Chtimes(path, header.AccessTime, header.ModTime) - 注意
Header.AccessTime和Header.ModTime在 Go 1.19+ 才被tar.Reader正确解析；旧版本需从Header.Xattrs或自定义扩展字段中提取
并发备份多个目录时，sync.Map 不适合存校验和，改用分片 map + sync.RWMutex
sync.Map 虽无锁，但不支持遍历，而增量逻辑常需对比“全量清单”；且其零值行为（如 LoadOrStore 返回 ok==false 时无法区分是未存还是存了零值）易引发校验误判。高并发下，单个 map 配 sync.RWMutex 更可控。
实操建议：
- 按文件路径哈希分片（如
hash := fnv.New32a(); hash.Write([]byte(path)); shardID := int(hash.Sum32() % 8)），维护 8 个独立map[string]checksum和对应RWMutex - 校验和计算用
io.Copy+hash.Hash流式处理，避免os.ReadFile全量加载大文件到内存 - 不要在 goroutine 中 defer
file.Close()后继续用该file——Go 的defer是函数返回时才执行，goroutine 可能已退出，文件句柄提前释放
增量逻辑里最容易被忽略的是时间精度：NTFS 和 ext4 的 ModTime 精度分别是 100ns 和 1s，跨文件系统备份时，仅比对秒级时间戳会导致漏备份。务必统一用 time.Truncate(time.Second) 对齐，或直接切到校验和比对。
