imaging.resize 一用就变形是因为默认强制拉伸而非等比缩放；传0可让某方向自适应，fit留白、fill裁剪；crop需手动计算左上角坐标并校验越界，顺序应先缩再裁；插值器选approxbilinear更稳妥。
imaging.Resize 为什么一用就变形？
imaging.Resize 默认不做等比约束，它只认你传的 width 和 height，强行拉伸填满——哪怕原图是 4:3，你给 300×150，结果就是压扁或拉长。
这不是 bug，是设计如此。它本质是「stretch-to-fit」，不是「scale-to-fit」。
- 传
0表示该方向按原始比例自动推算，比如imaging.Resize(img, 300, 0, imaging.Fit)→ 宽定为 300，高自适应 -
imaging.Fit：缩放到指定矩形内，不裁剪，可能留白 -
imaging.Fill：缩放到完全填满矩形，再居中裁剪掉溢出部分 - 别写
imaging.Resize(img, 300, 200, imaging.Lanczos)—— 这是变形高发写法
裁剪前必须手动算坐标，没有“以中心裁剪”快捷方式
imaging.Crop 的参数是 image.Rect(x, y, x+w, y+h)，原点在左上角，不是中心点。想从图中间抠个 200×200 正方形？得自己算起点：
- 先读尺寸：
w, h := img.Bounds().Max.X, img.Bounds().Max.Y - 再算左上角：
x := (w - 200) / 2，y := (h - 200) / 2 - 最后裁：
imaging.Crop(img, image.Rect(x, y, x+200, y+200))
常见错误：
- 忘记检查
x >= 0 && y >= 0 && x+200 ，越界会 panic - 把
image.Rect第四参数误当成「高度」，其实它是 Max.Y（即 y+h），写错就裁歪
缩放和裁剪顺序错了，结果就偏了
先裁再缩，等于在原始大图上随便切一块，再拉伸——关键区域可能早被切掉；
先缩再裁，才能确保目标区域在缩放后仍处于可定位范围。
- 正确顺序：
resized := imaging.Resize(..., imaging.Fill)→cropped := imaging.Crop(resized, ...) - 如果你用的是
image/draw，也要注意：先draw.Draw(dst, dst.Bounds(), src, src.Bounds(), draw.Over)缩放，再对dst做子图提取 -
image.SubImage返回的是视图引用，不是新图像；直接裁完拿去存，原图一改或 GC 回收，输出就花屏或 panic
用 draw.ApproxBiLinear 替代 CatmullRom，避免小图放大糊成一团
golang.org/x/image/draw 的默认插值器 draw.CatmullRom 太柔，尤其把 100×100 图放大到 800×600 时，边缘发虚、文字锯齿全丢。
- 生产推荐：
draw.ApproxBiLinear（质量/速度平衡）或draw.NearestNeighbor（像素风、图标类保锐） - 注意：源图要是
*image.RGBA，否则缩放后颜色异常；GIF 等调色板图需先转：rgba := imaging.Clone(src) - 目标尺寸必须为正整数，
0或负值会导致draw.Drawpanic
缩放裁剪这事，看着是两行函数调用，实际每步都卡在边界判断和顺序逻辑上。最容易漏的是：没校验裁剪坐标是否越界、没确认源图色彩模型、把 Resize 当等比缩放用——这些地方一松懈，上线后用户上传的图就各种变形糊黑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
