因为sync.Map是纯内存结构，每个Go进程（如Kubernetes的3个Pod）各自持有一份独立副本，彼此完全不通信，导致跨实例状态不同步；必须依赖Redis或PostgreSQL等外部存储提供一致视图。
为什么 sync.Map 不能用于跨实例同步状态
因为 sync.Map 是纯内存结构，每个 Go 进程（比如 Kubernetes 的 3 个 Pod）各自持有一份独立副本，彼此完全不通信。你在 Pod A 里标记 "config.yaml: synced"，Pod B 和 C 根本不知道——结果就是重复拉取、漏同步、甚至 checksum 冲突。真正需要的是外部一致视图，不是本地缓存。
轻量场景用 Redis：SET file_path "done" NX EX 3600 可防并发覆盖；强一致性必须上 PostgreSQL，建表存 file_path、checksum、sync_time，配合 ON CONFLICT DO UPDATE 实现幂等写入。
如何用 fs.WalkDir 安全生成待同步文件列表
别在回调里直接 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 为什么更稳
多 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 再优化。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
同步前怎么判断文件是否真要更新
不能只信 os.Stat 的 ModTime()——Windows NTFS 下实际精度只有 100ms，Go 返回的 100ns 是假象；NFS 或容器挂载也可能滞后。应组合判断：先比 Size() 和 ModTime()，都一致则跳过；否则流式计算 sha256.Sum256（前 8KB + 后 8KB），再 fallback 全量校验；小文件直接 bytes.Equal 全量比对更快。目标端已有同名文件且哈希一致，就彻底跳过复制。
原子更新必须做：先写临时文件（如 file.new），写完 os.Chmod 恢复权限，再用 os.Rename 替换原文件；跨设备时捕获 syscall.EXDEV 错误，fallback 到 io.Copy + os.Remove；符号链接、权限、Owner 信息需显式处理，os.Chown 在非 root 或 Windows 下失败应忽略而非中断。
