因为sync.map是进程内内存结构，多个go实例各自持有一份独立副本，彼此完全隔离，无法实现跨进程状态同步；必须依赖redis、postgresql等外部存储提供一致视图。
为什么不能直接用 sync.Map 管理同步任务状态
因为 sync.Map 是进程内内存结构，多个 Go 实例（比如 Kubernetes 部署的 3 个副本）各自持有一份独立副本，彼此完全不通信。你在一个实例里标记某个文件“已同步”，其他实例根本不知道——这会导致重复同步、漏同步甚至校验冲突。
真正需要的是跨进程一致的状态视图。常见做法是把任务进度写入外部存储：
- 轻量场景：用 Redis 的
SET key value NX EX 3600做首次同步锁，避免并发覆盖 - 强一致性要求：用 PostgreSQL 表存
file_path+checksum+sync_time，配合ON CONFLICT DO UPDATE - 断点续传必须项：checkpoint 必须和 sink 同可用区（如 Kafka 在
us-east-1，checkpoint 就不能存us-west-2的 S3）
如何用 fs.WalkDir 安全生成待同步文件列表
fs.WalkDir 是 Go 1.16+ 推荐方式，比旧版 filepath.Walk 更可控，但容易踩几个坑：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 别在回调里直接
panic或忽略错误——遇到syscall.ENOENT或os.ErrNotExist应跳过，不是遍历失败 - 过滤隐藏目录用
strings.HasPrefix(entry.Name(), ".")，别用filepath.Base拼路径，否则 Windows 下路径分隔符错乱 - 排除临时文件用
path.Match("*.tmp", entry.Name())，strings.HasSuffix不兼容 Windows 路径规则 - 遇到 symlink 循环时，
fs.WalkDir默认不会 panic，但若你在回调里主动调用entry.DirEntry().Info()再递归ReadDir，就可能触发死循环
并发拷贝时 io.Copy 配 io.LimitReader 比 io.CopyN 更稳
多 goroutine 并发读文件时，如果源文件被其他进程截断或删改，io.CopyN 会返回 io.ErrUnexpectedEOF 并中止，而 io.Copy + io.LimitReader(src, size) 能自然终止于实际字节数，返回 0, nil，语义更贴近“同步完成”。
另一个关键是 buffer 复用：
- 默认
io.Copy用 32KB buffer，够用；手动传make([]byte, 1)反而因 GC 压力拖慢吞吐 - 千级小文件场景下，用
sync.Pool管理 64KB buffer 可提升约 12% 吞吐，但代码复杂度上升，建议先跑 baseline 再优化 - 永远用
defer dst.Close()，哪怕dst是os.Create返回的*os.File
增量判断该用 os.Stat 还是双端哈希
os.Stat 的 Size() 和 ModTime() 对小文件通常足够，但有硬伤：
- Windows NTFS 下
ModTime()实际精度只有 100ms，Go 返回的 100ns 是假象，容易误判“已更新” - 大文件（>10MB）或高一致性要求（如金融日志）必须加一层校验：取前 64KB + 后 64KB 的
sha256.Sum256，再 fallback 全量校验 - 别用全量
sha256初筛——它会让 1GB 文件同步延迟从毫秒级拉到秒级 - 跳过逻辑必须同时满足：size 相同 + modtime 差值
os.O_SYNC 标志，机器掉电后最后几条 position 丢失，导致重启后重复同步或漏同步**。这不是理论风险，2026 年已有线上案例。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
