os.Stat 和 os.ReadDir 不能混用判断文件变更，因 NFS、容器挂载或 FAT32 下 ModTime 精度不足或不一致；应统一用 os.Stat 获取完整元数据，关键文件可先 os.ReadDir 筛选再单独 stat，并结合 Size、Mode 和 inode/index 做强校验。
为什么 os.Stat 和 os.ReadDir 不能混用判断文件变更
很多同步工具一上来就用 os.Stat 拿 ModTime 和 Size 做比对，但遇到 NFS、某些容器挂载或 Windows 的 FAT32 卷时，ModTime 可能被截断（秒级精度）或根本不可靠。更隐蔽的问题是：os.ReadDir 返回的 fs.DirEntry 不保证包含完整 FileInfo，调用其 Info() 方法可能触发额外系统调用，且在某些文件系统上返回的 ModTime 和直接 os.Stat 结果不一致。
实操建议：
- 统一使用
os.Stat获取完整元数据，避免混合调用 - 若需遍历性能优先（如大目录），先用
os.ReadDir筛路径，再对关键文件（如目标同步集）单独os.Stat - 不要依赖
ModTime唯一判定变更；必须结合Size+os.FileMode+ （可选）syscall.Stat_t.Ino（Linux/macOS）或syscall.ByHandleFileInformation.FileIndexLow（Windows）做强唯一性校验
如何用 io.Copy 安全地覆盖目标文件而不中断读写
直接 os.WriteFile 或 os.Create 覆盖正在被其他进程读取的目标文件，在 Linux 上虽不会报错，但旧进程仍持有原 inode 的句柄，导致磁盘空间不释放；Windows 则可能因文件锁定直接失败。
正确做法是：先写入临时文件，再原子替换。但注意 os.Rename 在同分区是原子的，跨分区会退化为复制+删除，且无法覆盖已存在文件（Windows 报 ERROR_ACCESS_DENIED）。
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 生成临时文件名用
filepath.Join(dir, "."+base+".tmp."+strconv.FormatInt(time.Now().UnixNano(), 36))，避免固定后缀被误删 - 写完后调用
os.Chmod(tmpfile, fi.Mode())保留权限 - 替换前先
os.Remove(dst)（Windows 必须），再os.Rename；封装成函数并检查err == nil || errors.Is(err, os.ErrNotExist) - 若需支持跨设备，改用
io.Copy+os.OpenFile(..., os.O_CREATE|os.O_WRONLY|os.O_TRUNC)，但要接受非原子性
fsnotify 监控事件为什么总漏掉或重复触发
fsnotify 底层依赖 inotify（Linux）、kqueue（macOS）、ReadDirectoryChangesW（Windows），但各平台语义差异极大。典型现象：保存 VS Code 文件时收到多个 Write 事件；用 cp 复制大文件时只收到一次 Create 却没 Write；删除文件夹时子项事件丢失。
根本原因不是库 bug，而是文件系统操作本身不“干净”：编辑器常先写临时文件再 rename，cp 可能用 sendfile 系统调用绕过 write 事件，递归删除由内核分批通知。
实操建议：
- 监听目录时，**必须递归添加子目录**（
watcher.Add(path)对每个子目录调用），fsnotify不自动递归 - 对
fsnotify.WriteEvent，不要立即处理，加 100ms 去抖（time.AfterFunc），合并连续写入 - 对
fsnotify.CreateEvent，检查是否为目录（os.Stat后判断IsDir()），是则立刻Add它 - 永远把监控当作“提示”，核心同步逻辑仍以全量扫描 + 时间戳/哈希比对为准，监控仅用于触发增量检查
大文件同步时如何控制内存与 I/O 压力
用 ioutil.ReadFile 读 GB 级文件会直接 OOM；用 io.Copy 默认 32KB 缓冲区，在千兆网或 NVMe 上吞吐不足；同时并发太多文件又会耗尽文件描述符或触发系统限流。
关键不是调大缓冲区，而是分层控制：
- 单文件传输用
io.CopyBuffer(dst, src, make([]byte, 1（1MB 缓冲），实测比默认快 3–5 倍 - 全局并发数用
semaphore.NewWeighted(int64(runtime.GOMAXPROCS(0)*2))控制，避免抢占式调度干扰 - 对 >100MB 文件，启用
syscall.Sendfile（Linux）或io.Copywithos.File（macOS/Windows），跳过用户态内存拷贝 - 始终用
dstFile.Sync()确保数据落盘，但避免对每个小文件都调用（聚合写入后批量 sync）
func copyWithSendfile(dst *os.File, src *os.File) error {
if runtime.GOOS != "linux" {
_, err := io.Copy(dst, src)
return err
}
srcFd := int(src.Fd())
dstFd := int(dst.Fd())
size, err := src.Stat()
if err != nil {
return err
}
_, err = syscall.Sendfile(dstFd, srcFd, nil, int(size.Size()))
return err
}
真正难的不是写对某一行代码，而是理解「同步」本质是状态收敛——文件系统没有事务，也没有全局时钟，所有优化都要让位于最终一致性。别迷信监控事件，也别省略全量校验。
