os.openfile配合io.copy不能直接用于可靠同步，因未保障源文件稳定性、内容一致性及目标写入原子性；需结合os.stat检查modtime稳定超2秒、哈希校验及临时文件+os.rename原子替换。
为什么 os.OpenFile 配合 io.Copy 不能直接用于可靠同步
因为文件可能正在被写入，os.OpenFile 默认不加锁，且 io.Copy 不校验内容一致性。你读到的可能是中间态数据，复制后目标文件看似“完成”，实则损坏。
真正同步需满足三点：源文件稳定（如已关闭）、内容可验证（如哈希）、目标写入原子（避免覆盖中被读）。常见错误是直接 os.Open + io.Copy 后就 os.Rename，但没检查源是否写完。
- 用
os.Stat检查ModTime是否超过 2 秒未变，作为“大概率写完”的信号（适用于日志轮转等场景） - 对小文件（sha256.Sum256 校验；大文件跳过或采样校验，避免阻塞
- 目标写入必须用临时文件 +
os.Rename，禁止直接os.Create覆盖原文件
如何用 fsnotify 监听文件变化但避开重复触发
fsnotify 在 Linux 上基于 inotify，但编辑器保存、cp、mv 等操作会触发多个事件（Write、Chmod、CloseWrite），直接响应会导致多次同步。
关键不是过滤事件类型，而是聚合判断“一次写入完成”。推荐做法：
- 监听
fsnotify.Write和fsnotify.CloseWrite两类事件 - 收到任一事件后，启动 100ms 延迟计时器；若期间再有同类事件，重置计时器
- 计时器到期后，才执行同步逻辑（即“静默期结束”）
- 注意：Windows 上
CloseWrite可能不触发，需 fallback 到Write+ 时间窗口兜底
同步时如何避免阻塞主线程又控制并发数
用 goroutine 处理每个待同步文件很自然，但不加限制会导致大量 goroutine 创建、磁盘 IO 拥塞、内存暴涨。别用 go syncFile(...) 无脑起协程。
实际应分两层控制：
- 外层用
sync.WaitGroup+chan struct{}控制最大并发数（例如 3 个同时传输） - 内层对每个文件，用
io.CopyBuffer配合 64KB 缓冲区，比默认 32KB 更适配 SSD 随机写 - 网络同步（如 rsync over HTTP）要设
http.Client.Timeout，否则一个卡住拖垮全部 - 本地文件同步不用加超时，但需捕获
syscall.EBUSY错误并重试（Windows 常见）
为什么不用 os.SameFile 判断源目标是否相同
os.SameFile 比较的是 inode 和 dev，只在同文件系统有效。跨分区、NFS、Docker volume 场景下必然返回 false，但它常被误用于“跳过相同文件”优化，结果导致不该跳过的也被跳过。
更安全的做法是分层判断：
- 先比路径字符串（忽略末尾
/），快速排除明显不同 - 再比
os.Stat的Size和ModTime，误差控制在 1 秒内（time.Since比较） - 最后对小文件做
sha256前 4KB + 后 4KB 校验（跳过中间），平衡速度与可靠性 - 永远不要假设
os.SameFile能替代内容比对
最易被忽略的点是时间精度：Linux ext4 默认只记录秒级 ModTime，而 NTFS 是 100ns 级。同一份文件 cp 到不同文件系统，ModTime 可能差几秒，仅靠时间比对会误判。必须结合大小和部分内容校验才稳妥。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
