绝大多数情况下要重试，但须区分错误类型：仅对syscall.ebusy、eio、enotempty等临时错误重试，exdev或权限错误需fallback为copy+remove，且重试前校验源文件存在、限制次数与间隔。
os.Rename 失败后要不要重试？
绝大多数情况下要，但必须区分错误类型。直接裸用 os.Rename 在生产环境大概率出事——它不是“失败就重试”的万能函数，而是原子操作的执行者，只管移动，不管上下文。
常见错误现象：syscall.EBUSY（Linux 上目标路径被其他进程以 O_PATH 打开）、syscall.EIO（NFS 挂载抖动）、os.ErrNotExist（目标父目录还没创建完）。这些在 K8s volume mount 延迟、容器冷启动、NAS 挂载不稳定时高频出现。
- 只对
syscall.EBUSY、syscall.EIO、syscall.ENOTEMPTY（Windows）这几类系统错误重试； -
syscall.EXDEV或os.ErrPermission是永久性错误，必须立刻降级为 copy + remove，不能重试； - 每次重试前先用
os.Stat(src)确认源文件是否还在，避免源被并发删除后无限重试； - 重试次数 ≤ 3，初始间隔 50ms，最大间隔 200ms；再长不如直接 fallback。
跨设备移动文件时怎么 fallback？
当 os.Rename 返回 syscall.EXDEV（Linux/macOS）或 ERROR_NOT_SAME_DEVICE（Windows），说明源和目标不在同一文件系统，原子移动不可能，必须走 copy + remove 路径。
关键点不是“复制完就完事”，而是保证语义等价：权限、所有者（如需）、atime/mtime 都得同步。Go 标准库不提供原子 copy，得自己组合 io.Copy + os.Chmod + os.Chtimes。
- 先用
os.Stat(src)获取源文件元信息； - copy 后立即调用
os.Chmod(dst, fi.Mode())和os.Chtimes(dst, fi.Atime(), fi.Mtime())； - remove 源文件前确认 copy 成功，否则留脏数据；
- 整个 fallback 过程不参与重试逻辑——它本身就是重试失败后的确定性兜底动作。
读取文件遇到 io.EOF 怎么处理才不算“重试”？
io.EOF 不是错误，是正常信号，把它当错误重试会引发逻辑混乱甚至死循环。很多开发者误以为“读不到内容就 retry”，结果反复打开同一个文件，卡在 EOF 上原地打转。
正确做法是：只要 Read 返回 n > 0，就先处理已读数据；只有 n == 0 && errors.Is(err, io.EOF) 才表示真正读完；其他 err（如 os.ErrPermission、syscall.ENOENT）才考虑是否重试。
- 不要对
io.EOF做任何重试或 sleep； - 对
os.IsPermission(err)或os.IsNotExist(err)这类错误，重试无意义，应立即报错或 fallback； - 若读取逻辑依赖外部状态（如配置文件被另一个进程热更新），可对
syscall.EAGAIN或syscall.EINTR做轻量重试（1–2 次，无退避）。
手写重试逻辑比引入 backoff 库更合适？
对文件操作这类低频、非高并发场景，20 行内手写比引入 github.com/cenkalti/backoff/v4 更轻量、更可控。第三方库的通用性反而会掩盖文件操作特有的边界条件。
核心是三个必须显式处理的点：context 取消感知、错误分类判断、指数退避。漏掉任意一个，线上都可能卡死或雪崩。
- 每次循环开头检查
ctx.Err() != nil，立即返回； - 用
errors.As(err, &e)提取syscall.Errno，再做e == syscall.EBUSY判断； - 退避延迟用
time.Duration(1，但上限设为 200ms，避免单次操作拖太久； - 最后一下重试成功前不 sleep，避免无谓等待。
文件操作的重试不是“多试几次就能好”，而是精准识别临时性干扰、快速降级、严格守界——最易被忽略的是：重试前没预检目录，或 fallback 时没同步时间戳，导致后续程序因 mtime 错乱误判缓存失效。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
