应加去重延迟机制并校验文件哈希：记录事件路径最后处理时间，100ms内重复丢弃；Rename时识别编辑器临时操作并等待Remove或超时；预加载路径监听，跳过无关目录；更新前先比Size/ModTime，一致则跳过，否则流式计算SHA256判断是否真变更。
用 fsnotify 监控文件变化但不触发重复事件
直接监听目录时，fsnotify 常因编辑器写入临时文件（如 .swp、~ 备份）、原子写入（先写新文件再 rename）导致同一逻辑变更触发多次 Write 或 Create。关键不是过滤事件类型，而是加一层去重和延迟判断：
- 对每个
Event.Name记录最后处理时间，100ms 内重复事件直接丢弃 - 遇到
Rename事件，优先检查是否是编辑器的临时重命名（如从file.tmp→file），此时应等待原路径的Remove事件或超时后统一按“内容更新”处理 - 避免监听整个大目录，改用
filepath.WalkDir预加载当前文件列表，只对已知路径注册监听，跳过node_modules、.git等无关子目录
同步前比对文件是否真正需要更新
不能仅靠修改时间（ModTime）判断——NFS、某些容器挂载、Windows FAT32 下该字段可能不精确或滞后。实际应组合校验：
- 先快速比较
Size()和ModTime()，两者都一致则跳过 - 否则计算
SHA256哈希（用io.Copy+hash.Hash流式计算，不全量读入内存） - 若目标端已有同名文件，且哈希一致，直接跳过；否则才触发复制
- 注意：小文件（bytes.Equal 全量比对，更快
用 os.Link 和 os.Rename 实现原子更新
覆盖写目标文件存在风险：写到一半中断会导致损坏。正确做法是「写新+原子替换」：
- 在目标目录同级创建临时文件（如
file.new），写入完毕后调用os.Chmod恢复权限 - 用
os.Rename替换原文件——该操作在同文件系统下是原子的；跨文件系统失败时 fallback 到io.Copy+os.Remove - 更优解是用
os.Link创建硬链接指向新文件，再os.Remove旧文件（适用于 Linux/Unix），避免磁盘写放大 - 务必检查
os.Rename返回的syscall.EXDEV错误，这是跨设备的明确信号
处理符号链接与权限丢失问题
默认 os.Copy 只复制内容，丢失 symlink、chmod、chown 信息。需显式处理：
立即学习“go语言免费学习笔记（深入）”；
- 用
os.Lstat获取源文件元数据，判断fi.Mode()&os.ModeSymlink != 0，若是则用os.Readlink+os.Symlink - 复制完内容后，用
os.Chmod(dst, fi.Mode())恢复权限；注意 Windows 不支持os.ModeSetuid等位，需屏蔽 -
os.Chown在非 root 用户或 Windows 下会失败，应忽略错误而非中止同步 - 如果目标是远程（如 SFTP），这些元数据需编码进自定义协议头，无法依赖 OS 层语义
ModTime 和哈希都可能失效，这时候必须依赖本地持久化的同步日志（比如用 boltdb 记录每个文件的上次成功同步版本号）。 
