fsnotify不能直接替代轮询，因其会丢失批量重命名、跨文件系统移动、编辑器原子写入、nfs等场景的内核事件，需配合修改时间+大小校验或低频扫描兜底。
为什么 fsnotify 不能直接替代轮询做文件同步
因为 fsnotify 只监听内核事件，而很多场景下它会丢事件：比如批量重命名、跨文件系统移动、编辑器（如 VS Code）的原子写入（先写临时文件再 rename）、NFS 挂载点等。单纯依赖 fsnotify 容易漏同步，必须配合轻量级校验（如修改时间 + 文件大小）或周期性扫描兜底。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用
fsnotify.Watcher监听Write、Create、Remove、Rename四类事件，但不信任其完整性 - 对监听路径启动一个低频（如 5 秒间隔）的
filepath.WalkDir扫描，只比对最近修改时间（FileInfo.ModTime()）和大小，跳过内容全量比对（太慢） - 避免在
fsnotify回调里直接执行复制——需发到带缓冲的 channel，由独立 goroutine 顺序处理，防止事件洪水导致并发冲突
如何用 os.Symlink 和 os.Readlink 正确处理符号链接同步
默认 io.copy 或 os.ReadFile 会自动解引用符号链接，导致把目标文件内容复制过去，而非同步链接本身。要保留链接结构，必须显式判断并重建。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 同步前用
os.Lstat(path)替代os.Stat，检查Mode() & os.ModeSymlink != 0 - 若为链接，用
os.Readlink(src)读取目标路径，再在目标目录调用os.Symlink(target, dst) - 注意 windows 上
os.Symlink需管理员权限或启用开发者模式，可加runtime.goOS == "windows"分支 fallback 为复制内容（需明确日志告警）
怎样让 sync/atomic 安全地统计并发同步进度
多个 goroutine 同时更新同步计数器时，用普通 int 会导致竞态；用 sync.Mutex 又太重（高频更新下锁开销明显）。atomic 是更合适的选择，但要注意类型匹配和内存序。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 声明计数器用
var totalFiles int64，更新用atomic.AddInt64(&totalFiles, 1)，读取用atomic.LoadInt64(&totalFiles) - 不要用
int类型变量传给atomic函数——Go 会报错，且int在 32 位系统上非原子 - 如果还需统计失败数，单独用另一个
int64变量，不要试图用位运算塞进同一个变量（可读性差，无实际收益）
为什么 os.Chmod 在 linux 同步后常失效，以及怎么修
Linux 下复制文件默认用 os.Create，新文件权限是 umask 掩码后的结果（通常是 0644），不会继承源文件权限。即使你调用了 os.Chmod(dst, srcInfo.Mode())，也可能因目标文件已存在且被其他进程占用而失败（chmod: operation not permitted）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 创建目标文件时直接指定权限：
dstFile, err := os.OpenFile(dst, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, srcInfo.Mode().Perm()) - 若目标文件已存在，先
os.Chmod再写入（注意：必须在os.Write前，否则可能被覆盖回默认权限） - 忽略
chmod的EPERM错误（常见于只读挂载或容器 rootfs），但记录日志，避免静默失败
同步逻辑越简单，越容易暴露权限、符号链接、事件丢失这些底层细节。别指望一次监听就稳，得把“监听 + 快速扫描 + 权限/链接专项处理”当默认组合来写。