imaging.resize 默认拉伸变形，应改用 imaging.fit 或 imaging.fill 保持比例；裁剪需手动计算左上角坐标，image.rect 参数为 (x, y, x+w, y+h)。
用 imaging.Resize 缩放图片时，宽高比容易被意外破坏
默认情况下 imaging.Resize 是「拉伸填充」模式，不保持原始比例。如果你传入 width=200 和 height=150，它会强行把图塞进这个框里，导致变形。
- 保持比例缩放：用
imaging.Fit（等比缩放到指定矩形内，不裁剪）或imaging.Fill（等比缩放到填满矩形，再居中裁剪） - 常见错误写法：
imaging.Resize(img, 300, 200, imaging.Lanczos)→ 变形风险高 - 正确示例：
img = imaging.Resize(img, 300, 0, imaging.Fit)（只设宽度，高度自动计算） -
0表示该方向按比例推导，不是“不限制”——这是很多人卡住的第一步
imaging.Crop 裁剪坐标原点是左上角，但容易误当中心点用
裁剪区域由 x, y, width, height 四个参数决定，全部基于图像左上角（0, 0）起算。没有内置“以中心为基准”的快捷方式，得自己算。
- 想从中心裁 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)) - 注意：
image.Rect的第四个参数是Max.X，不是宽度；别写成x+200, y+200就完事——它确实是，但得确认x+200 且 <code>y+200 ，否则 panic - 裁剪前建议加边界检查，尤其处理用户上传图时尺寸不可控
缩放 + 裁剪组合操作必须注意顺序：先缩放再裁剪
如果先裁再缩，可能把关键区域切掉；如果先缩再裁，才能确保目标区域在缩放后仍可精准定位。顺序错了，结果就偏了。
- 典型流程：
Resize → Crop，比如生成头像：先等比缩到略大于目标尺寸（如 400×400），再从中心裁出 200×200 - 反例：
Crop → Resize会导致原始图中一小块被拉伸，画质劣化更明显，且裁剪位置难预测 - 性能上，先缩放能减小后续操作的像素量，尤其对大图（>2MB）更明显
- 别省那一步变量赋值——把
img = imaging.Resize(...)明确写出来，避免链式调用时搞混中间状态
读取和保存时注意格式与 Alpha 通道兼容性
imaging 库本身不处理文件 IO，靠 image.Decode 和 jpeg.Encode 等标准库函数。但 PNG 有透明通道，JPEG 没有，直接保存会丢信息或 panic。
- 读图时用
image.Decode，它返回的是image.Image接口，底层类型可能是*image.RGBA或*image.NRGBA - 写 JPEG 前务必转换：
img = imaging.Clone(img)或显式转成*image.RGBA，否则可能报invalid JPEG format - PNG 可保留 Alpha，但浏览器渲染时若没设 CSS
background，透明区域会显示为灰白——这不是代码问题，是前端配合点 - 保存路径要确保目录存在，
os.OpenFile不会自动建父级目录，容易因no such file or directory失败
实际用起来，最常掉坑的地方不是 API 不熟，而是忘了 resize 的 mode 参数、裁剪前不校验坐标范围、以及在 JPEG 场景下忽略颜色模型转换。这些点不报错，但输出图要么歪要么花要么根本写不进去。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
