不能直接用 image.decode 提取元数据，因为它只解码像素数据，不解析 exif、iptc 或 xmp 等元数据块；必须直接解析文件头部二进制结构，推荐 github.com/rwcarlsen/goexif/exif（jpeg/tiff）或 github.com/h2non/bimg（多格式）。
Go 图像元数据提取为什么不能直接用 image.Decode？
image.Decode 只负责解码像素数据，不读取 EXIF、IPTC 或 XMP 等元数据块。如果你需要相机型号、拍摄时间、GPS 坐标或版权信息，必须绕过标准解码器，直接解析文件头部的二进制结构。
常见错误是先调用 image.Decode 再试图从 io.Reader 中二次读取——此时 reader 已被消耗，后续读取返回空或错位数据。
- 正确做法：用
os.Open获取*os.File，再用file.Seek(0, io.SeekStart)重置偏移量，或用bytes.NewReader复制原始字节 - 推荐库：
github.com/rwcarlsen/goexif/exif（支持 JPEG/TIFF）和github.com/h2non/bimg（底层调用 libvips，支持更多格式但需 C 依赖） - 注意：PNG 和 WebP 基本不带 EXIF；HEIC 需额外处理 MIE 容器
如何用 Go 提取稳定图像指纹（感知哈希）？
MD5/SHA256 这类加密哈希对缩放、旋转、亮度调整极度敏感，不适合图像去重或相似检索。你需要的是感知哈希（pHash），它基于 DCT 变换后的低频系数生成 64-bit 整数。
Go 生态中成熟度高的是 github.com/corona10/goimagehash，它实现了平均哈希（aHash）、差分哈希（dHash）和 pHash，且不依赖 CGO。
- 使用前务必统一尺寸：
Resize(8, 8, bimg.Nearest)（pHash 要求 32×32，aHash/dHash 用 8×8） - 灰度转换必须做：
color.GrayModel.Convert，否则 RGB 三通道会干扰哈希一致性 - 避免用
image/jpeg.Decode后再转灰度——JPEG 解码可能引入轻微色度抽样误差，建议用bimg直出灰度图
并发解析大量图像时，exif.Decode 报 EOF 怎么办？
这不是 bug，而是 exif.Decode 默认只扫描前 64KB 寻找 EXIF header（0xFFE1），而某些相机生成的 JPEG 元数据可能藏在更靠后的位置，或者被编辑软件写入了多个 APP1 段。
解决方法是传入自定义 exif.Options，扩大扫描范围：
opts := exif.Options{SkipThumbnail: true, MaxSize: 2 * 1024 * 1024} // 扫描前 2MB
exifdata, err := exif.Decode(bytes.NewReader(raw), opts)
- 不要盲目设成
math.MaxInt64——大文件会显著拖慢解析速度 - 若仍失败，可先用
bytes.Index手动定位[]byte{0xFF, 0xE1}，再截取后续 4 字节长度字段，精准提取 APP1 段 - 注意：Go 1.21+ 的
io.ReadAll在读取超大文件时可能触发内存限制，建议用io.ReadFull分块读取
生成哈希后怎么高效比对相似图像？
直接两两计算汉明距离是 O(n²)，10 万张图就要 100 亿次比较。实际部署必须用局部敏感哈希（LSH）或预排序策略。
最轻量的做法是把 64-bit pHash 当作整数，按 bit 数分桶（如每 8 bit 一组，共 8 个 byte）：
hash := imghash.PHash(img) buckets := make([]uint8, 8) for i := 0; i > (i * 8)) & 0xFF) } // 存入 Redis：HSET phash:buckets[0] buckets[1]... hash
- 查相似图时，只比对同一 bucket 下的哈希值，再筛选汉明距离 ≤ 10 的候选
- 注意：pHash 对镜像不鲁棒，若需支持翻转，应额外计算垂直/水平翻转后的哈希并入库
- 别忽略 I/O 瓶颈——哈希计算快，但磁盘随机读取慢；建议把元数据 + 哈希一起序列化为
gob或msgpack批量写入 SSD
真正麻烦的不是算法本身，而是不同相机厂商对 EXIF 标签的私有扩展（比如 Canon 的 MakerNote），这部分没公开 spec，只能靠样本逆向和容错解析。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
