fsnotify是实时同步起点但不能直接当同步工具用，因其仅通知文件变更事件，不提供内容比对、冲突解决、断点续传等同步必需能力，需配合os.Stat校验、SHA256哈希、重试去抖及自定义决策逻辑。
Go语言本身不提供开箱即用的实时文件同步或双向备份能力，必须靠组合标准库（如fsnotify）+ 自定义逻辑实现；直接用os.Copy或ioutil.WriteFile只能做单次、单向、非实时操作。
为什么fsnotify是实时同步的起点，但不能直接当同步工具用
Go标准库没有内置文件监听，fsnotify是事实标准——它封装了Linux的inotify、macOS的FSEvents和Windows的ReadDirectoryChangesW。但它只负责“通知你文件变了”，不负责“怎么同步”“冲突怎么处理”“断网后怎么续传”。
- 它发出来的
fsnotify.Event里只有路径和操作类型（Write、Create、Remove），没有文件内容、哈希或修改时间戳的完整比对能力 - 多个连续
Write事件可能对应一次保存，但fsnotify会发多次，不做去抖（debounce）就会重复同步 - 重命名（
Rename）在不同系统上行为不一致：Linux下mv可能被拆成Remove+Create，而macOS可能只发一个Rename，需额外状态跟踪
os.SameFile和os.Stat怎么判断“该不该同步”
仅靠文件名或路径相等无法决定是否要复制——源文件可能被修改过，也可能目标已存在但内容陈旧。必须结合元数据与内容校验：
- 先用
os.Stat获取源/目标的ModTime()和Size()，若源更新且大小不同，大概率需要同步 - 但
ModTime可能被篡改或精度不足（如FAT32只有2秒粒度），所以关键文件建议加一层crypto/sha256校验（小文件可全量算，大文件可读前几KB+末尾几KB） - 用
os.SameFile(srcInfo, dstInfo)快速排除“源=目标”的硬链接或同一文件，避免自拷贝 - 注意：
os.Symlink和os.Readlink需单独处理，否则同步可能把符号链接变成实际文件内容
双向同步时，“冲突”到底指什么，os.Rename不是万能解
双向同步真正的难点不在“复制”，而在“决策”：当A目录删了file.txt，B目录同时改了file.txt，谁为准？Go没有内置冲突解决策略，所有逻辑得自己写。
立即学习“go语言免费学习笔记（深入）”；
- 常见策略有三种：
source-wins（以触发事件方为准）、newer-wins（按修改时间）、backup-on-conflict（冲突时保留双方，生成file.txt.conflict-20260601-1111） -
os.Rename看似能原子替换，但它在跨文件系统时会失败（返回syscall.EXDEV），此时必须退化为os.Copy+os.Remove，而这两步不是原子的——中间出错会导致目标残留半成品 - 删除操作最难处理：收到
Remove事件后，不能立刻删目标，得先确认源端确实删了（而不是网络延迟导致事件乱序），否则误删不可逆
维护阶段最容易被忽略的三个细节
上线后最常崩的不是主逻辑，而是这些边缘case：
- 临时文件干扰：编辑器（如VS Code）保存时先写
file.txt~再rename，或Git写.git/index.lock，必须用filepath.Base过滤掉以.或~开头的路径 - 权限丢失：
os.Copy不复制文件权限，需用dstInfo.Sys().(*syscall.Stat_t).Mode()（Linux/macOS）或os.Chmod手动还原 - 长路径/非法字符：Windows下路径超260字符、NTFS流文件（
file.txt:zone.identifier）会被os.Open静默跳过，需用golang.org/x/sys/windows调用CreateFile带FILE_FLAG_BACKUP_SEMANTICS
