增量备份判断文件修改的核心是先用modtime()和size()初筛，一致则跳过；否则进行内容哈希校验，不一致则报错并支持--force强制覆盖，目录变更通过filepath.walk扫描比对。
增量备份怎么判断文件是否被修改
核心是避免全量比对，用元数据 + 内容指纹组合判断。单纯依赖 os.FileInfo.ModTime() 不可靠——编辑器可能只改内存、保存时触发写入延迟，或 NFS/挂载卷时间不同步；os.FileInfo.Size() 也容易误判（比如日志轮转后清空但大小不变）。
实操建议：
- 先检查
ModTime()和Size()是否都未变，若一致则跳过；否则进入内容校验 - 对小文件（sha256.Sum256；大文件用分块哈希（如每 1MB 块算一次
sha256，再对块哈希序列做一次最终哈希），避免内存暴涨 - 把哈希值存到本地状态文件（如
.backup_state.json），键为相对路径，值含modtime、size、hash，下次备份前读取比对
同步时如何避免覆盖新内容
目标端已有更新、源端旧版本覆盖过去，是同步逻辑最常踩的坑。不能只看“源是否变更”，得双向比较时间戳和哈希。
实操建议：
- 同步前先拉取目标端对应文件的
stat信息（通过 SSH 执行stat -c "%Y %s" file或用 SFTP 客户端调Stat()） - 若目标端
ModTime()> 源端，且哈希不一致，中断同步并报错"target is newer, manual conflict resolution required" - 允许加
--force参数强制覆盖，但必须显式打印警告，并记录到日志（含源/目标时间戳与哈希） - 对目录结构变更（新增/删除文件），用
filepath.Walk扫描源端，再逐个查目标端是否存在，而不是依赖 rsync 式的 delta 传输
如何高效传输差异块（非全量重传）
真正做增量同步时，文件内容只变几行，但传统方式仍传整个文件。Go 标准库没内置 bsdiff 或 rsync 协议实现，得自己裁剪。
Golang Spf13 Viper
下载
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
实操建议：
- 用
github.com/klauspost/compress/zstd对原始文件做流式压缩，再对比压缩后字节流的哈希——压缩对相似内容敏感，能粗筛出“大概率未变”的文件，省去完整哈希计算 - 对确认变更的文件，用
github.com/golang/freetype/raster？不，那是字体库。正确选择是github.com/DataDog/zstd或手写基于bytes.Equal的行级 diff（适用于文本日志），但注意换行符兼容性（\nvs\r\n） - 生产环境建议走成熟协议：用
rsync --write-batch生成 patch 文件，Go 只负责调度命令和校验 exit code；或者用git apply配合生成的 unified diff（前提是目标端有 git）
状态持久化与并发安全怎么设计
多个 goroutine 同时处理不同文件，共享的状态文件（如哈希记录、进度标记）若无保护，会写坏或丢失更新。
实操建议：
- 状态文件用
json.Encoder配合os.O_WRONLY | os.O_CREATE | os.O_TRUNC写入，每次全量覆盖，而非追加——避免解析损坏的中间态 - 读写状态前加文件锁：
github.com/gofrs/flock，锁文件设为.backup_state.lock，防止同一目录下多个备份进程冲突 - 每个文件的哈希计算用独立 goroutine，但写入状态前统一 gather 到主 goroutine，用
sync.WaitGroup等待全部完成后再落盘 - 状态结构体字段加
json:",omitempty"标签，避免空字段污染 JSON；时间戳统一用UnixNano()存整数，跨平台兼容
真正的难点不在算法多巧妙，而在状态文件被杀进程、磁盘满、NFS 断连时能否自愈。每次启动先校验状态文件 JSON 有效性，损坏就重建，别卡死。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
