识别损坏文件头需读取前8–12字节比对魔数：PNG为0x89504E470D0A1A0A，JPEG以0xFFD8FF开头，ZIP为0x504B0304；须用os.Open和io.ReadFull精确读取，避免bufio干扰，修复时用os.OpenFile+Seek+Sync确保落盘。
如何识别并定位损坏的特定格式文件头
修复前必须确认损坏位置，尤其要验证文件头是否被截断或覆写。常见格式如 PNG、JPEG、ZIP 都有固定魔数（magic bytes），直接读取前 8–12 字节就能快速排除误判。
用 os.Open 打开文件后，用 io.ReadFull 读取固定长度字节到 []byte，避免因文件过短导致 panic；别用 bufio.NewReader 做首部检测——它内部缓冲可能提前读多，干扰魔数比对。
- PNG 应以
[]byte{0x89, 0x50, 0x4E, 0x47, 0x0D, 0x0A, 0x1A, 0x0A}开头 - JPEG 是
[]byte{0xFF, 0xD8, 0xFF}起始，但注意某些变体含 APP0 段，建议至少校验前 3 字节 - ZIP 文件头为
[]byte{0x50, 0x4B, 0x03, 0x04}，若缺失，大概率是末尾数据被截断或头部被零填充覆盖
用 os.OpenFile 安全覆盖损坏头并保留原内容
不能直接 os.Create 覆盖原文件——会清空全部内容。必须用 os.OpenFile 以 os.O_RDWR | os.O_CREATE 模式打开，并配合 file.Seek(0, 0) 回到开头写入修复头。
写入后务必调用 file.Sync()，否则操作系统可能只缓存未落盘，重启后修复丢失；尤其在批量处理时，漏掉这步会导致“看似修复成功，实则无效”。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 写入长度必须严格等于目标格式头长度，多写会破坏后续结构（如把 ZIP 的文件条目表覆盖掉）
- 如果原文件头部分损坏但长度尚可（例如 PNG 头第 5 字节错为
0x00），优先只重写错误字节，而非整段重写 - 修复前建议先用
filepath.Base提取文件名，加.repaired后缀生成备份路径，用os.Rename原地替换，降低风险
修复 ZIP 文件时为什么不能只补文件头
ZIP 损坏常表现为中央目录丢失或末尾偏移错乱，仅补 0x50 0x4B 0x03 0x04 只能让解压器识别为 ZIP，但无法列出或解出任何文件——因为真正关键的是末尾的中央目录结束记录（EOCD），它包含目录起始偏移和条目数。
若 EOCD 完全丢失，需扫描整个文件从后往前找最后一个 0x50 0x4B 0x01 0x02（目录条目签名），再估算其位置；但更稳妥的做法是调用 archive/zip 包的 zip.NewReader 并捕获 zip.ErrFormat，它通常比 io.ErrUnexpectedEOF 更明确指向结构缺陷。
- 不要手动拼接 EOCD 结构体——字段顺序、大小端、disk number 等极易出错
- 可用
github.com/mholt/archiver/v4的archiver.Zip.Read尝试解析，它比标准库容错稍强，适合预检 - 若文件实际内容完整，只是 EOCD 偏移错位，用
hexdump -C file.zip | tail -20手动查最后几个 KB，常能定位残留的50 4B 05 06（EOCD 签名）
并发修复多个文件时如何避免 I/O 饥饿和句柄泄漏
用 runtime.GOMAXPROCS 控制 goroutine 数量没用——瓶颈在磁盘 I/O，不是 CPU。应限制并发打开的文件数，推荐用带缓冲的 channel 做信号量，比如 sem := make(chan struct{}, 4)，每启动一个修复任务前 sem ，完成后 <code><-sem。
每个 goroutine 内必须确保 file.Close() 执行，哪怕发生 panic。最简方式是用 defer file.Close()，但要注意：如果 file 是 nil（例如 os.Open 失败），defer 会 panic。应在 if file != nil 分支里 defer。
- 别用
filepath.Walk直接递归所有文件——遇到符号链接循环或超深目录易卡死，改用filepath.Glob("*.zip")或os.ReadDir分层控制 - 修复失败的文件应记录完整路径和错误（如
fmt.Errorf("failed to repair %s: %w", path, err)），而不是只打印err.Error()，否则无法区分是权限问题还是格式不匹配 - 日志建议写入独立文件，而非 stdout，避免和进度提示混在一起，尤其在 shell 管道中执行时
修复工具的核心不在“写得多”，而在“读得准、写得稳、控得细”。最容易被忽略的是：修复 ZIP 时只盯着开头，却忘了结尾的 EOCD 才决定它能不能被真正解出来。
