filepath.walk仅适合一次性全量拷贝，不可靠于生产同步；真正可靠需事件监听+差异判断+安全写入三者配合。
filepath.Walk 不能直接用于生产环境的文件同步 —— 它不感知变更、不处理冲突、不支持断点续传，只适合一次性全量拷贝。
真正可靠的 Go 文件同步，得靠事件监听 + 差异判断 + 安全写入三者配合。下面分几个实操关键点说清楚。
如何用 inotify/fsevents 实现 Linux/macOS 文件变更监听
Go 标准库不提供跨平台文件系统事件 API，必须依赖第三方包，比如 fsnotify（最常用）。它在 Linux 下用 inotify，macOS 用 FSEvents，Windows 用 ReadDirectoryChangesW。
常见错误是监听路径没做 filepath.Abs 校验，导致相对路径监听失败；或监听后没忽略编辑器临时文件（如 *~、.swp），引发重复触发。
- 监听前先调用
filepath.Abs(src)获取绝对路径，避免符号链接或相对路径歧义 - 用
event.Op&fsnotify.Write == fsnotify.Write判断是否为内容修改，而非仅属性变更 - 对
Create和Write事件，建议加 100ms 去抖（debounce），防止编辑器保存时多次写入触发多次同步 - 务必用
err := watcher.Add(path)检查监听是否成功，某些 NFS 或容器挂载路径会静默失败
为什么并发复制文件时目标文件经常为空或损坏
根本原因不是 goroutine 本身有问题，而是文件句柄复用和写入模式错误。多个 goroutine 共享一个 *os.File，或目标文件用 os.O_APPEND 打开，都会导致内容错乱或截断。
- 每个 goroutine 必须独立调用
os.Open打开源文件，禁止传入已打开的*os.File - 目标文件必须用
os.O_CREATE | os.O_WRONLY | os.O_TRUNC打开，确保覆盖而非追加 -
io.Copy后必须显式调用dst.Close()，否则缓冲区数据可能未落盘 - 若源文件可能被轮转（如日志），应在
os.Stat后立即os.Open，避免中间被替换
如何安全控制并发数避免 too many open files
不限流启动几百个 goroutine 复制小文件，会在几秒内耗尽系统文件描述符（Linux 默认通常 1024），报错 too many open files，且内存暴涨。
- 用带缓冲 channel 做信号量：例如
sem := make(chan struct{}, 10)限制最多 10 并发 - 启动 goroutine 前先
sem ，结束后 <code> 释放 - 不要只靠
sync.WaitGroup等待——它不管启动节奏，只管收尾 - 对大文件（>50MB），建议单独走串行通道，避免单个 goroutine 长时间阻塞信号量
备份同步失败时怎么重试才不算瞎重试
网络存储、USB 设备、权限受限目录下，io.Copy 可能返回 io.ErrUnexpectedEOF、syscall.EACCES、syscall.ETIMEDOUT 等具体错误。字符串匹配错误信息极易漏判或误判。
- 统一用
errors.Is(err, syscall.EACCES)或errors.Is(err, io.ErrUnexpectedEOF)判断，比strings.Contains(err.Error(), "permission")更可靠 - 对可恢复错误（如网络超时），建议指数退避重试（最多 3 次），间隔从 100ms 开始翻倍
- 对不可恢复错误（如
syscall.ENOSPC磁盘满），应立刻停止任务并告警，而不是反复重试写入 - 每次失败后记录结构化日志，包含文件路径、错误类型、时间戳，方便定位是路径问题还是权限问题
实际落地时，最难的不是写通逻辑，而是在监听、判断、复制、清理四个环节之间保持状态一致性。比如监听到一个 Write 事件，刚打开源文件，进程被 kill，这个半截文件就可能留在目标目录里。这类边界情况，需要结合临时文件名 + 原子 rename 来兜底，不能只靠“尽量保证”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
