重试逻辑应封装在完整读取动作层，如readfilewithretry函数，覆盖打开、读取、关闭全流程，避免仅重试os.open导致后续read失败不重试或文件句柄泄漏。
文件读取失败时 retry 逻辑该放在哪一层
重试不能直接塞进 os.Open 调用里——它只负责打开，而真正的失败常发生在后续的 Read、ReadAll 或 io.Copy 过程中。更合理的做法是把重试封装在「完整读取动作」上，比如封装一个 ReadFileWithRetry 函数，覆盖打开 + 读取 + 关闭全流程。
常见错误是只对 os.Open 做重试，结果文件打开了但磁盘瞬间掉线，Read 报 read: connection reset by peer 或 input/output error 却不再重试。
- 重试边界要包含
defer f.Close()的执行，否则多次重试可能泄漏文件句柄 - 不要在
for循环里反复调用os.Open后不Close，这是典型资源泄漏点 - 网络文件系统（如 NFS、SMB 挂载）或 USB 设备拔插场景下，
io.EOF或syscall.EIO出现频率远高于本地磁盘
retry 参数怎么设才不拖慢主流程
固定间隔重试（如每次 sleep 100ms）在瞬时 IO 故障下有效，但面对设备短暂离线，可能连续失败 5 次后才恢复；而指数退避（exponential backoff）更稳妥，但要注意上限——别让一次读取卡住整个服务几秒。
time.Sleep 前必须检查是否已超总 timeout，否则可能违反调用方 SLA。
- 推荐初始 delay 为
10 * time.Millisecond，每次 ×2，最大不超过500 * time.Millisecond - 总 timeout 建议显式传入，例如
ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second) - 若使用
context.Context控制超时，每次重试前先select { case
哪些错误值得重试，哪些该立刻返回
不是所有 error 都适合重试。比如 os.IsNotExist(err) 表示文件根本不存在，重试一百次也没用；而 os.IsTimeout(err) 或底层 syscall.EAGAIN/syscall.EINTR 才是典型可重试信号。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
Golang 标准库不会把 syscall 错误自动转成高级语义错误，所以得自己 inspect err 的底层类型。
- 值得重试：
os.IsTimeout、errors.Is(err, syscall.EAGAIN)、errors.Is(err, syscall.EINTR)、errors.Is(err, syscall.EIO) - 绝不重试：
os.IsNotExist、os.IsPermission、errors.Is(err, io.ErrUnexpectedEOF)（说明文件已损坏或截断） - 注意：
io.EOF是正常结束信号，不是错误，不应纳入重试判断
用 io.ReadFull 替代 io.ReadAll 的实际影响
很多场景下你以为读完了，其实只读了部分数据——比如 NFS 缓存未刷盘、USB 设备响应延迟，io.ReadAll 可能提前返回少于预期的字节却不报错。这时用 io.ReadFull 配合预分配 buffer，能强制要求「必须读满」，失败时自然触发重试。
但代价是：你得知道文件大小上限，否则 buffer 分配过大浪费内存，过小则频繁 realloc。
- 若文件大小已知（如配置文件、JSON blob），优先用
io.ReadFull+make([]byte, size) - 若大小未知，可用
stat.Size()先获取，但注意os.Stat本身也可能失败，需单独加一层轻量重试 - 避免在重试循环里反复
make大 buffer，应在外层一次性分配并复用
重试逻辑看似简单，但真正落地时，context 超时传递、错误分类粒度、buffer 复用和 close 时机这四点，漏掉任何一个都容易在线上跑出 goroutine 泄漏或静默数据截断。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
