os.Rename跨设备必然失败，错误为syscall.EXDEV；须捕获该错误后降级为复制+删除，并同步权限、时间戳，大文件需流式处理且调用dst.Sync()确保落盘。
跨设备移动文件时 os.Rename 会失败并返回 invalid cross-device link
Go 的 os.Rename 在 Linux/macOS 上底层调用的是 rename(2) 系统调用，它要求源路径和目标路径必须在同一个挂载点（即同一文件系统）。一旦跨越设备（比如从 /tmp 移动到 /home，而二者属于不同磁盘分区），就会返回 invalid cross-device link 错误。这不是 Go 的 bug，而是 POSIX 的限制。
此时不能靠重试或包装 os.Rename 解决，必须切换策略：先复制、再校验、最后删除源文件 —— 但这个过程本身不是原子的，需要你自己控制“原子性边界”。
用 io.Copy + os.Remove 实现可中断但最终一致的移动
真正的原子性在跨设备场景下无法由单个系统调用保证，只能靠应用层设计“失败可恢复”的流程。关键不是“一步完成”，而是“每步可逆/可判别状态”。推荐顺序：
- 用
os.Open打开源文件，os.Create创建目标文件（注意：目标路径父目录必须存在） - 用
io.Copy复制内容（它内部自动处理 buffer 和 partial write） - 调用
dstFile.Sync()确保数据落盘（避免缓存未刷导致后续校验失败） - 用
os.Stat比对源/目标文件的Size()和ModTime()（必要时加sha256校验） - 校验通过后，执行
os.Remove(srcPath)
如果中途 panic 或 crash，残留的是完整的目标文件 + 原始源文件，不会出现“半截文件”。只要程序重启后能识别出目标已存在且完整，就跳过复制直接删源。
立即学习“go语言免费学习笔记（深入）”；
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
为什么不用 filepath.Walk 递归移动整个目录？
filepath.Walk 只是遍历工具，不解决原子性问题；而且目录跨设备移动时，子项可能分布在不同挂载点（比如符号链接指向其他磁盘），单纯遍历 + 逐个 os.Rename 仍会失败。
更实际的做法是：对每个文件单独走“复制+校验+删除”流程；对子目录，先 os.MkdirAll 创建目标路径，再递归处理其内容。注意：
- 权限（
FileInfo.Mode()）需显式设置到新文件/目录上 - 软链接要区分处理：
os.Readlink获取目标，再用os.Symlink重建，而不是复制内容 - 不要试图用
cp -r调用外部命令 —— 丢失错误上下文、无法做细粒度校验、难以处理中断
临时文件写入 + 原子替换是唯一接近“原子”的方案
如果目标路径已有文件，且你希望更新操作具备“要么全生效、要么不变”的语义，必须借助临时文件 + os.Rename 替换：
- 在**目标文件所在设备**上创建临时文件（如
dstPath + ".tmp"） - 写入内容并
Sync() - 用
os.Rename(tmpPath, dstPath)—— 这步是原子的，且同设备内 rename 总是成功 - 最后才删源文件（如果这是移动而非覆盖）
这个模式常见于日志轮转、配置热更新等场景。但注意：它只保证“目标路径的可见性切换”是原子的，不保证源文件删除也包含在原子范围内 —— 所以严格来说，跨设备移动没有真正意义上的单系统调用原子操作，只有分阶段的、有明确状态边界的可靠流程。
最容易被忽略的是 Sync() 调用时机和位置：漏掉它，断电或 crash 后可能得到一个长度正确但内容损坏的文件，而 Size() 校验完全无法发现。
