image.decode 读取失败主因是解码器未注册（如 webp/bmp）、文件未用 io.readseeker 包裹、图片头部损坏；缩略图推荐 disintegration/imaging；验证码需加载 ttf 字体并先渲染后扭曲；png.encode 失败多因 content-type 未设、writer 异常或误用 buf.string()。
image.Decode 读取图片失败，常见原因是什么
image.Decode 不是万能的“自动识别器”，它依赖注册的解码器。默认只注册了 png、jpeg、gif 三种格式，且对 jpeg 的 MIME 类型敏感（比如 image/jpg 不会被识别）。
- 如果传入的是
.webp或.bmp文件，会直接 panic：image: unknown format - 用
os.Open打开文件后，没用io.ReadSeeker包裹（比如直接传*os.File），某些格式（如jpeg）可能 decode 失败 - 图片头部损坏或不完整（网络流中截断、HTTP 响应体未读完），
image.Decode会返回unexpected EOF
建议始终用 image.Decode 配合 bytes.NewReader 或显式 io.Copy 到内存 buffer，避免底层 reader 被多次读或提前关闭。
缩略图生成时，resize 用哪个库更稳
Go 标准库没有内置 resize 函数，必须引入第三方。实际项目中，github.com/disintegration/imaging 是最轻量、兼容性最好的选择，比 golang.org/x/image 更成熟，也比 github.com/nfnt/resize（已归档）更维护活跃。
-
imaging.Resize支持双线性插值（imaging.Lanczos效果更好但稍慢），默认用imaging.Linear平衡速度与质量 - 注意目标尺寸为 0 会 panic，需提前校验
width和height是否 > 0 - 若原图是 palette 模式（如某些 GIF），
imaging.Resize会自动转换为 RGBA，但 alpha 通道可能丢失——需要手动调用imaging.ToRGBA再 resize
示例关键行：
立即学习“go语言免费学习笔记（深入）”；
img := imaging.Resize(src, 200, 0, imaging.Lanczos)其中
0 表示等比缩放，高度自动计算。
验证码图片文字扭曲后看不清，draw.String 怎么调才靠谱
draw.Draw 只负责像素合成，文字绘制靠 golang.org/x/image/font/basicfont + golang.org/x/image/font/opentype。标准库字体太小太硬，直接用 basicfont.Face7x13 画验证码，基本不可读。
- 必须加载真实 TTF 字体（如
DejaVuSans.ttf），否则中文和斜体都出不来 - 文字位置不能写死，要用
font.Face.Metrics算基线，否则不同字号下上下偏移严重 - 扭曲不是靠 draw，而是先渲染到一张干净
*image.RGBA，再用imaging.Warp或逐像素映射变形；强行用draw.Src叠加扭曲图层会导致边缘锯齿爆炸
容易漏的一点：验证码图必须设置 Content-Type: image/png，且写入前清空 HTTP header 中可能残留的 text/plain。
image/png.Encode 写出的图片浏览器打不开
image/png.Encode 本身没问题，问题几乎全出在 writer 上。
- HTTP response writer 被提前 close 或超时中断（尤其开发时用 curl 测试没加
-v，看不到 502） - 图片数据写入前，忘了调用
w.Header().Set("Content-Type", "image/png")，浏览器当文本解析，显示乱码 - 使用
bytes.Buffer中转时，忘记用buf.Bytes()而误用buf.String()（对二进制 png 数据，String()会破坏字节）
还有一个隐蔽坑：如果图片是 <em>image.NRGBA</em>，而你用 png.Encode 写入，它能工作，但部分老浏览器解析 alpha 通道异常；统一转成 image.RGBA 更稳妥，用 imaging.Clone 或 imaging.ToRGBA 即可。
生成流程里最容易被跳过的环节，其实是错误传播——png.Encode 返回 error，但很多人只 log 不 return，导致后续 write 发生 panic。
