标准库 image/draw.Draw 本身不提供“采样函数”抽象，它只接受预定义的 draw.Op（如 draw.Src、draw.Over）和插值器（如 draw.NearestNeighbor）。真正做缩放采样的逻辑，实际来自第三方 resize 库（如 nfnt/resize）或 imaging 内部封装。直接拿 image/draw 比“采样函数”是错的——它压根不负责重采样，只负责像素块复制或叠加。
nfnt/resize 的六种插值器性能差异真实表现
它不是理论排序，而是实测在 1920×1080 → 400×300 缩放下的耗时与内存行为：
-
resize.NearestNeighbor：最快，约 1.8ms，零额外内存分配，但锯齿明显；适合图标、像素画、UI资源生成 -
resize.Bilinear：4.2ms，临时分配约 16KB 权重缓存，质量可接受，网页缩略图首选 -
resize.MitchellNetravali：9.7ms，需预计算 32×32 插值核表，内存占用比双线性高 3 倍，照片类内容推荐 -
resize.Lanczos2和resize.Lanczos3：分别耗时 14.5ms / 21.3ms，sinc 计算触发大量浮点运算和 cache miss；Lanczos3 在 4K 图上可能吃满单核，且对齐要求严（尺寸需为偶数），否则边缘发虚
⚠️ 注意：nfnt/resize 默认使用 image.RGBA 输入，若传入 *image.YCbCr 会先转 RGBA，额外增加 8–12ms 开销——别跳过类型检查。
imaging.Resize 为什么比 nfnt/resize 快但接口更“黑盒”
imaging 库把插值逻辑和内存复用打包在一起，不暴露插值器参数，但做了三件事让实际吞吐更高：
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 内部复用
sync.Pool缓存中间图像缓冲区，避免每次缩放都make([]uint8, w*h*4) - 对
NearestNeighbor和Bilinear路径做了汇编优化（Go 1.21+ 的unsafe.Slice直写 Pix），跳过Set()方法调用开销 - 自动 fallback：当目标尺寸 ≤ 源尺寸 1/4 时，改用多级 box filter（先平均下采样再插值），比单步 Lanczos 快 2.3 倍
代价是：你没法控制 Lanczos 的 a 参数，也不能把插值器单独拎出来复用——它绑定在 imaging.Resize 调用里。
别在热路径里自己实现双线性插值
常见错误是看到 “双线性很简单”，就手写一个逐像素 At(x,y) + 四点加权，结果比 nfnt/resize.Bilinear 慢 5–7 倍。原因很实在：
-
image.Image.At()每次调用都做边界检查 + 颜色模型转换（比如从 YCbCr 转 RGBA），开销远高于直接读Pix[] - 没做 cache line 对齐，CPU 频繁换行读内存；而
nfnt/resize是按 scanline 批量处理，局部性好 - 没向量化：现代 CPU 的 SIMD 指令（AVX2）在
imaging和nfnt中都被启用，手写代码默认不触发
真要定制插值逻辑，正确做法是：先用 img.(*image.RGBA) 断言拿到 Pix，再用 unsafe.Slice 转成 [][4]uint8，最后按 stride 手动索引——但这已脱离“采样函数”范畴，进入底层像素编程了。
插值器选型不是看文档写的“高质量”，而是看你的输入尺寸、输出尺寸比、是否批量、是否允许轻微 aliasing。Lanczos3 在单图精修时有意义，在 CDN 缩略图服务里就是性能毒药。
