Go标准库无image.Resize因定位为格式抽象而非图像处理；缩放需用golang.org/x/image/draw或手写最近邻，推荐ApproxBiLinear插值并注意类型匹配与编码兼容性。
为什么 image.Resize 不存在？先别找这个函数
Go 标准库没有 image.Resize 这种开箱即用的缩放函数。这是新手最常卡住的第一步——搜了文档、翻了 image 包，发现只有 image.Decode、image.NewRGBA 这类基础构造器，没有“一键缩放”。原因很简单：image 包定位是图像格式抽象和像素操作，不内置采样算法；缩放属于图像处理逻辑，得自己组合实现。
真正能用的路径只有两条：用 golang.org/x/image/draw（官方扩展包，含双线性等插值）或手写最近邻（简单但质量差）。别试图魔改 image/subsample 或硬套 draw.Filler——它们不解决缩放问题。
用 draw.BiLinear 缩放 PNG/JPEG 的最小可行代码
这是实际项目里最稳的选择：支持常见格式、插值质量可接受、无额外依赖（除了 x/image/draw）。注意它不修改原图，而是把源图“画”到目标尺寸的新图像上。
- 必须先解码为
image.Image，不能直接对*os.File操作 - 目标图像需手动创建，尺寸由你指定，类型建议用
image.NRGBA（Alpha 通道兼容性最好） -
draw.BiLinear是插值器，不是函数名——传给draw.Draw的第四个参数 - JPEG 解码后通常是
*image.YCbCr，而draw.Draw要求目标为draw.Image（如*image.NRGBA），类型不匹配会 panic
src, _, _ := image.Decode(f) bounds := src.Bounds() dst := image.NewNRGBA(image.Rect(0, 0, 300, 200)) // 目标宽高 draw.Draw(dst, dst.Bounds(), src, bounds.Min, draw.BiLinear)
draw.ApproxBiLinear 和 draw.CatmullRom 有什么区别？
三者都是 draw.Resampler 接口实现，但质量和速度差异明显：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
draw.NearestNeighbor：最快，块状锯齿，适合缩略图预览或像素风 -
draw.ApproxBiLinear：比BiLinear略快，视觉差别极小，Go 官方示例常用它 -
draw.CatmullRom：更平滑，尤其对文字/线条缩放效果好，但计算稍重，小图几乎看不出差别 - 所有 resampler 对 alpha 通道都做线性混合，如果源图有半透明边缘，缩放后不会突兀断裂
别在 CLI 工具里为省几毫秒换 NearestNeighbor——人眼分辨不出，反而容易被吐槽“图片糊了”。默认用 ApproxBiLinear 就行。
缩放后保存失败？检查这三处 io.Writer 和格式编码
缩放完存不了文件，90% 出在编码环节，和缩放本身无关：
-
jpeg.Encode要求输入是image.Image，但如果你传了*image.NRGBA（它实现了），没问题；传*image.RGBA64就可能 panic——JPEG 不支持 16bit 通道 -
png.Encode支持更多类型，但若源图是*image.Gray，直接 encode 可能变灰度 PNG；想强制彩色，得先转成*image.NRGBA - 写文件时用
os.Create后忘了defer f.Close()，会导致文件句柄泄漏，多次运行后报too many open files
一个安全写法：os.OpenFile(path, os.O_CREATE|os.O_WRONLY|os.O_TRUNC, 0644)，避免权限或截断问题。
image.Config 检查——这些地方没日志、没提示，一错就白屏或黑图。 
