直接用Go自研文件一致性校验逻辑在多数生产场景下属于高成本低收益——除非已明确排除Syncthing、etcd+对象存储等成熟方案，否则应优先复用现有机制，聚焦业务层校验。
直接用 Go 自研文件一致性校验逻辑，在多数生产场景下属于高成本低收益——除非你已明确排除 Syncthing、etcd + 对象存储、或 MinIO 版本控制等成熟方案，否则优先复用已有机制，把精力放在业务层校验逻辑上。
为什么不能只靠 fsnotify + os.Stat 做一致性判断
fsnotify 是本地事件监听器，它不保证事件顺序、不递归监听子目录、也不感知远程节点变更。常见错误现象包括：
-
fsnotify.Create事件触发时，文件可能还在写入中（尤其大文件），os.Stat返回的Size为 0 或远小于最终值 - rename 操作在 Syncthing 中是先写
.tmp再原子重命名，监听Create就读空文件；监听Rename又可能漏掉非 .tmp 后缀的中间态 - 多个节点同时修改同一路径，
os.Stat().ModTime()在 NFS 上不可靠（NFSv3 不同步 mtime，v4 需noac），无法作为版本依据
Go 程序安全读取同步完成文件的三个动作
必须组合使用事件类型过滤、文件状态确认、内容哈希比对，三者缺一不可：
- 监听
fsnotify.Write和fsnotify.Rename，但忽略所有Event.Name以.tmp结尾的事件 - 收到非临时文件事件后，先调用
os.Stat检查Size > 0且Mode().IsRegular()为 true - 再用
sha256.New()+io.Copy流式计算哈希，并与预期值（来自元数据库或客户端 Header）比对；不要用md5.Sum([]byte{})，改用md5.Sum(nil)防止切片复用污染
校验失败时该做什么，而不是立刻 panic
一致性校验失败 ≠ 数据损坏，而是信号：当前视图与权威源存在偏差。此时应分层响应：
立即学习“go语言免费学习笔记（深入）”；
- 单节点校验失败：记录日志 + 触发
os.Remove+ 从对象存储（如 MinIO）重新拉取，避免本地脏数据污染后续流程 - 多节点哈希不一致：暂停该文件服务，查询 etcd 中
/dfs/versions/{file-id}的最新版本号和各节点上报的hash，定位异常节点 - 高频失败（如 1 分钟内超 3 次）：自动将该路径加入
quarantine列表，跳过自动同步，人工介入检查磁盘健康或网络丢包
真正难的不是“怎么算哈希”，而是确定“谁的哈希是权威”以及“校验失败后如何恢复信任”。这要求你在设计之初就明确元数据存储位置（etcd / PostgreSQL）、租约机制（lease ID 绑定文件块）、以及修复通道（是否走后台 goroutine 还是触发告警工单）。
