热备份需保证源文件可读写且备份结果反映一致时间点状态；os.Copy和filepath.WalkDir因无原子性与事务语义，无法满足该要求。
热备份不是“边读边拷”，而是要求源文件在备份过程中可被其他进程持续读写，且备份结果仍能反映某个一致时间点的状态。Go 标准库本身不提供原子快照能力，必须结合 OS 特性或外部工具实现；直接用 io.Copy 或 os.Copy 遍历复制，本质仍是冷备份。
为什么 os.Copy 和 filepath.WalkDir 无法满足热备份
它们只是顺序读取当前文件内容，不阻塞源文件，但也不保证一致性：若一个日志文件在遍历中途被追加写入，备份里可能包含截断的最后几行；若某个配置文件在读取一半时被覆盖重写（如编辑器先清空再写入），备份得到的是损坏碎片。
-
os.Stat和os.Open是两个独立系统调用，中间存在时间窗口，文件可能被删、重命名或权限变更 -
filepath.WalkDir不锁定目录，readdir结果可能漏掉刚创建或刚删除的条目 - 没有事务语义，无法回滚部分失败的复制操作
Linux 下可用的热备份基础：copy-on-write 文件系统快照
真正可行的热备份路径，是依赖底层存储支持 COW（如 Btrfs、ZFS、LVM thin-provisioning）。Go 工具只需调用对应命令创建快照，再从快照挂载点做普通备份。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- Btrfs：
btrfs subvolume snapshot -r /data /data/.snap/backup_$(date +%s)，然后filepath.WalkDir遍历/data/.snap/backup_12345 - ZFS：
zfs snapshot pool/data@backup_12345，再zfs clone或直接访问.zfs/snapshot/backup_12345 - 务必检查快照是否只读（
-r参数或readonly=on属性），否则备份过程本身可能污染快照 - 快照创建后需确认挂载点就绪（
os.Stat检查目录存在且可读），再启动备份流程，避免 race
Windows/macOS 上的替代方案：Volume Shadow Copy（VSS）与 APFS 快照
Windows 可通过 robocopy /b 调用 VSS，但 Go 无法直接调用 COM 接口；更现实的做法是封装 PowerShell 命令：vssadmin create shadow /for=C:，提取 \?GLOBALROOTDeviceHarddiskVolumeShadowCopy123 路径，再用 os.ReadDir 访问。macOS APFS 支持 tmutil localsnapshot，生成的快照位于 /.fseventsd/locks/ 下隐藏路径，需用 findmnt 或 diskutil apfs list 解析。
- 不要硬编码快照路径，每次执行前动态解析 —— VSS ID 和 APFS UUID 都是运行时生成的
- VSS 快照默认 10 分钟自动释放，备份耗时超过阈值需提前延长生命周期（PowerShell 调用
Set-VssBackupOptions） - APFS 快照不可写，但 macOS 对快照内符号链接的解析行为和主卷略有差异，测试时注意
os.Readlink是否返回空
备份完成后必须清理快照，否则磁盘会满
快照不是备份，只是临时一致性视图；备份数据落盘后，快照即失去价值。Go 工具应在 defer 或 recover 中确保清理逻辑执行，哪怕主流程 panic。
- Linux Btrfs：
btrfs subvolume delete /data/.snap/backup_12345，失败时记录日志但不中断主流程（快照残留比备份失败危害小） - Windows VSS：
vssadmin delete shadows /for=C: /quiet，注意匹配正确的 Shadow ID，避免误删其他应用快照 - 所有清理命令都应设置超时（
cmd.WaitDelay = 30 * time.Second），防止挂起整个工具 - 最危险的是“快照创建成功 → 备份失败 → 忘记清理”，建议在快照路径中嵌入 PID 或随机 token，清理时 glob 匹配带该标识的路径，降低误删概率
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
