最可靠的图片损坏判断依据是 image.decode 能否返回非 nil 的 image.image，需显式注册格式、用可重读的 io.reader、校验尺寸并限制大图内存，仅靠后缀或魔数不可靠。
用 image.Decode 检查图片是否能正常解码
Go 标准库的 image.Decode 是最直接的损坏判断依据：它不关心格式细节，只管“能不能读出像素”。只要返回非 nil 的 image.Image，就说明文件结构基本完整；如果报错（比如 image: unknown format 或 invalid JPEG format），大概率是头损坏、截断或伪造后缀。
注意别只看 err == nil 就认为安全——有些损坏图片（如末尾缺字节的 PNG）可能被部分解码成功但内容异常。建议加一层尺寸校验：img.Bounds().Size() 至少大于 (1,1)，避免空图误判。
- 必须显式注册格式：在
main()开头调用image.RegisterFormat("jpeg", "jpeg", jpeg.Decode, jpeg.DecodeConfig)等，否则image.Decode对常见格式返回unknown format - 传入的
io.Reader需支持多次读取（比如用bytes.NewReader(data)包装原始字节），因为Decode内部可能 Seek 或重读 - 对大图做内存限制：先用
image.DecodeConfig读宽高，若超过阈值（如 10000×10000）直接跳过，防止 OOM
为什么不能只靠文件后缀或魔数判断
后缀只是字符串，魔数（如 89 50 4E 47）只能验证开头几个字节。很多损坏场景根本绕过这两层：比如 JPEG 文件中间字节被随机覆盖、PNG 的 IDAT 块 CRC 校验失败、WebP 的 VP8 帧数据损坏——这些情况下魔数仍正确，后缀也对，但实际无法渲染。
真实项目中遇到过一批“能用浏览器打开但 Go 解码失败”的图，查下来是导出工具写入了非法 EXIF 数据，破坏了 JPEG 的段结构。这类问题只有走到 image.Decode 才暴露。
立即学习“go语言免费学习笔记（深入）”；
- 用
http.DetectContentType只能粗筛，对损坏不敏感，且不支持 WebP、AVIF 等较新格式 - 检查
os.Stat().Size()是否为 0 有用，但对“有内容但损坏”的情况完全无效 - 真正可靠的信号只有一个：标准解码器能否吐出合法
image.Image
并发处理时如何避免 goroutine 泄露和 panic
批量检测天然适合并发，但 image.Decode 在遇到恶意构造的输入时可能 panic（比如超长 Huffman 表的 JPEG），而 goroutine 内 panic 若不捕获会直接终止整个程序。
别用 recover 包裹整个 goroutine——它无法恢复已发生的资源泄漏。正确做法是把解码逻辑封装成带超时和 recover 的函数，并限制最大 goroutine 数量。
- 用
sem := make(chan struct{}, 10)控制并发数，每启动一个 goroutine 前sem ，结束后 <code> - 解码函数内用
defer func(){ if r := recover(); r != nil { err = fmt.Errorf("panic during decode: %v", r) } }() - 给
os.Open加context.WithTimeout，防止卡死在慢磁盘或 NFS 上
Windows 下路径和编码的坑
Go 的 filepath.Walk 在 Windows 上默认用系统代码页解析路径名，如果目录含中文或特殊符号（如 测试图①.jpg），可能返回 no such file or directory 错误，即使文件真实存在。
这不是 Go 的 bug，而是 Windows API 层级的历史包袱。解决方案不是改 Go 源码，而是绕过 filepath.Walk，改用 os.ReadDir + 手动递归。
-
os.ReadDir返回的fs.DirEntry名称是 UTF-16 解码后的字符串，能正确处理中文路径 - 避免用
filepath.Join拼接路径再传给os.Open，改用entry.Name()和dirPath构造绝对路径 - 对
os.Open的错误，区分os.IsNotExist(err)和其他类型；后者可能是权限或编码问题，需单独记录而非跳过
复杂点在于：你得同时处理 Linux/macOS 的符号链接循环、Windows 的 NTFS 硬链接、以及某些云存储挂载点返回的伪路径。这些没法靠一个函数兜底，得按运行环境分路径策略。
