go的image.decode需手动注册解码器并依赖文件头magic number，未注册或流截断会导致“unknown format”；web上传须以字节为准而非content-type；缩略图插值选approxbilinear（快）或catmullrom（锐，慎用）；jpeg编码默认quality=75易糊，建议90；png转jpeg需铺白底；并发时须隔离buffer与rgba实例，大图需限流。
缩略图生成卡在 image.Decode 读不到图片？检查文件头和格式注册
Go 的 image.Decode 不会自动猜格式，它只认已注册的解码器（比如 jpeg.RegisterFormat），而且必须依赖文件开头几个字节（magic number）匹配。常见错误是传入网络流或截断的 buffer，导致返回 "image: unknown format"。
- 确保在 main 或 init 中显式调用
jpeg.RegisterFormat()、png.RegisterFormat()、gif.RegisterFormat()—— Go 1.19+ 仍需手动注册，标准库不会默认全开 - 如果从
*os.File或bytes.Reader读取，先用io.LimitReader取前 512 字节送入image.DecodeConfig验证格式，避免整张大图加载失败 - Web 场景下用户上传的
Content-Type不可信，别用它判断格式；以实际 bytes 为准
用 draw.ApproxBiLinear 还是 draw.CatmullRom？看场景不看“高级”
缩略图质量不是越“高阶”越好。插值算法影响的是重采样时像素混合方式，但代价是 CPU 和内存占用明显上升，尤其对批量任务。
-
draw.ApproxBiLinear：速度快、内存低、视觉足够干净，适合头像、商品列表图等 200×200 级别缩略图 -
draw.CatmullRom：边缘锐度更好，但计算量翻倍，仅建议用于导出高清预览图（如 >800px 宽）且单次调用 - 别在循环里反复 new
draw.CatmullRom实例——复用一个全局变量即可，它本身无状态
jpeg.Encode 输出模糊或色偏？注意 *jpeg.Options 的默认值陷阱
Go 标准库 jpeg.Encode 默认用 Quality: 75，看似合理，但很多前端开发者没意识到：这个值不是“百分比”，而是量化表索引，75 对应中高频细节大量丢失，人眼容易觉得“糊”。
- 想接近原图观感，设
&jpeg.Options{Quality: 90}是更安全的起点；超过 95 后体积激增，收益极小 - 如果输入是 PNG（带 alpha），直接 encode 成 JPEG 会丢弃透明通道并填充黑底——必须先用
image.NewRGBA+draw.Draw手动铺白底 - 输出到 HTTP 响应时，记得设
w.Header().Set("Content-Type", "image/jpeg")，别依赖浏览器 sniff
并发缩略图时内存暴涨？别让 image.Decode 和 draw.Draw 共享同一块 buffer
多个 goroutine 并发处理图片时，如果共用一个 bytes.Buffer 或复用 image.RGBA 底层 slice，会出现像素错乱或 panic：”slice bounds out of range“。
立即学习“go语言免费学习笔记（深入）”；
- 每个 goroutine 必须独立 decode：用
bytes.NewReader(src)包一层，而不是传共享的[]byte - 目标图像尺寸确定后，用
image.NewRGBA(image.Rect(0, 0, w, h))新建，别复用旧的*image.RGBA - 大图（>5MB）建议加限流：用
semaphore.NewWeighted(3)控制同时 decode 的数量，防 OOM
真正麻烦的从来不是 API 调用几行代码，而是 decoder 注册漏了、buffer 复用错了、alpha 通道没处理——这些点一错，图就废，还不好 debug。
