多节点状态同步必须用可追溯的变更日志+轻量发现协议，因os.SameFile和filepath.Walk仅作用于本地、无法感知远程节点及冲突状态，单点快照搬运必然导致静默不一致；应采用内容哈希+版本日志实现最终一致性，并用memberlist实现自动发现与容错。
多节点状态同步不能靠单机机制模拟，必须用可追溯的变更日志 + 轻量发现协议，否则必然出现静默不一致。
为什么 os.SameFile 和 filepath.Walk 无法用于多节点状态比对
这两个 API 完全不感知远程节点存在。os.SameFile 只比较本机 inode 或 volume+index；filepath.Walk 扫出的只是当前快照，既不包含其他节点的删除动作，也无法表达“文件在 A 已删、在 B 还存在”这类冲突状态。常见错误现象是：节点 A 删除后手动 rsync 到 B，但中间 B 接收了新上传请求，导致 /media 下瞬间不一致且无审计痕迹。
- Windows 下应优先用
filepath.WalkDir，它比filepath.Walk更可靠，但仍解决不了跨节点收敛问题 - 大小预筛 + 分块哈希（如首尾 1MB）只适用于离线校验，不能作为同步驱动逻辑
- 任何基于本地 fs 操作的“同步脚本”，本质都是单点快照搬运，不是状态同步
用内容哈希 + 版本日志实现最终一致性
核心是放弃“实时同步”，转而构建可重放的变更流。每个文件由 sha256 命名，每次变更生成一条带单调递增 version 的日志记录。
- 文件不可变：
a1b2c3/image.jpg一旦写入，禁止覆盖；更新即新哈希 + 新日志项 - 本地日志建议用 SQLite 或 WAL 文件，字段至少含：
version INTEGER PRIMARY KEY、file_hash TEXT、op TEXT CHECK(op IN ('add', 'delete')) - 同步触发时机：节点每 30s 向集群广播自己的
currentVersion；收到邻居更低版本号时发起 HTTP GET 拉取缺失条目 - 拉取到
add事件后，先HEAD检查远端文件是否存在且哈希匹配，再GET下载；delete事件则直接os.Remove对应路径
用 memberlist 实现无中心自动发现与容错重试
硬编码 IP 列表或依赖 DNS 会破坏扩展性与故障隔离能力。HashiCorp 的 memberlist 库稳定、轻量、无外部依赖，适合 ≤ 50 节点中小规模集群。
立即学习“go语言免费学习笔记（深入）”；
- 初始化时传入本机地址和端口，加入同一 gossip cluster 即可自动交换成员状态
- 不要把业务数据塞进
UserData字段，它只适合传version这类轻量元信息 - 监听
MemberEventCh获取上线/下线事件；下线节点的未完成同步任务需标记为stale，后续由 leader 节点兜底重试
真正难的不是写同步逻辑，而是定义“状态”的粒度——是按文件、按目录、还是按业务实体？一旦粒度选错，日志膨胀、冲突检测成本、回滚复杂度都会指数上升。这个判断必须在设计第一天就锁定，后续几乎无法重构。
