golang.org/x/image 读写图片时不会自动丢弃 Exif，需显式剥离；标准库 image/jpeg 等仅处理像素，jpeg.Encode 会原样保留 APP1 段；推荐用 github.com/rwcarlsen/goexif.Remove 清理 JPEG 的 Exif。
用 golang.org/x/image 读写图片时，Exif 不会自动丢弃
Go 标准库的 image/jpeg、image/png 等包只处理像素数据，完全无视 Exif。哪怕你用 jpeg.Decode 读进来再用 jpeg.Encode 写出去，原始 JPEG 文件里的 Exif 段（APP1）大概率原封不动跟着写回去了——因为编码器根本不解析也不清理它。
常见错误现象：exiftool image.jpg 显示 “Make: Canon”、“DateTime: 2022:03:15 14:22:08”，但你代码里明明只做了 resize 和重存。
- 必须显式剥离 Exif，不能依赖解码+编码流程自动清除
-
golang.org/x/image本身不提供 Exif 操作能力，得额外引入解析/修改逻辑 - 如果图片是 PNG 或 WebP，Exif 支持更弱（PNG 用 iCCP、tEXt 等 chunk 存少量元数据；WebP 的 EXIF 是可选 VP8X 扩展，Go 官方库目前不处理）
用 github.com/rwcarlsen/goexif 剥离 JPEG 的 Exif 最直接
这个库专注做一件事：读取和删除 JPEG 中的 APP1（Exif）段。它不碰像素、不重编码，只做字节级裁剪，快且安全。
使用场景：上传头像、生成缩略图、CDN 预处理等需要“干净像素”的环节。
立即学习“go语言免费学习笔记（深入）”；
- 先用
ioutil.ReadFile（或os.ReadFile）读原始[]byte，别走image.Decode流程 - 调用
exif.Remove，传入原始字节，返回剔除 Exif 后的新字节切片 - 再把结果写回文件或交给
image.Decode处理（此时已无 Exif 干扰） - 注意：该库仅支持 JPEG，对 PNG/WebP 无效，强行传入会返回错误或原样返回
示例：
data, _ := os.ReadFile("photo.jpg")
cleanData, err := exif.Remove(data)
if err != nil {
// 处理 err，比如不是 JPEG 或无 APP1 段
}
os.WriteFile("clean.jpg", cleanData, 0644)
用 github.com/xrash/smetrics 或手动跳过 Exif 解析 JPEG
如果你只需要 decode 出图像并忽略 Exif（比如做 OCR、滤镜、尺寸判断），又不想多一次 IO 读写，可以跳过 Exif 解析阶段，避免 jpeg.Decode 内部尝试读取 APP1 导致 panic 或卡顿。
标准库 image/jpeg 在 decode 前会扫描 marker，遇到不认识的 APPx 段默认跳过——但某些损坏或非标 Exif 可能触发 invalid JPEG format: invalid marker 错误。
- 用
jpeg.Decode时传入自定义*jpeg.Options，设置IgnoreExif = true（Go 1.21+ 才支持） - 旧版本 Go（github.com/xrash/smetrics 的
jpeg.DecodeNoExif替代，原理是提前截断 APP1 段再交给标准解码器 - 不要自己写 marker 扫描逻辑——JPEG marker 结构有嵌套和长度字段，容易漏判或越界
WebP 和 PNG 的元数据清理要分情况对待
WebP 有独立的 EXIF 负载区（在 VP8X chunk 后），但 Go 官方 golang.org/x/image/webp 当前（v0.19.0）不暴露任何元数据接口；PNG 的 tEXt、zTXt、iTXt、iCCP 等 chunk 也全被标准 image/png 忽略。
- 若需清理 WebP 的 EXIF，得用
github.com/chai2010/webp或调用cwebp命令行加-noexif参数 - PNG 清理推荐用
github.com/disintegration/imaging的Save函数，默认不写入任何文本 chunk；或用png.Encode前手动构造*png.Encoder并设CompressionLevel: png.NoCompression（不影响元数据，但可控制输出行为） - 最省事的办法：统一转成无元数据格式（如无损 PNG），再用对应库保存——但要注意色深、透明通道是否丢失
真正麻烦的是混合来源图片：同一服务既要处理用户上传的 JPEG（含 GPS）、又要接 iOS 截图（PNG + xmp）、还要兼容微信转发的 WebP（带版权信息）。这时候得按 MIME 类型分流，各自用对应策略，没法一套逻辑通吃。
