用golang.org/x/image/draw缩放图片模糊是因为默认CatmullRom插值过柔，小图放大时失真；推荐ApproxBiLinear（平衡）或NearestNeighbor（保锐），并注意源图有效性、色彩模型转换及尺寸合法性。

用 golang.org/x/image/draw 缩放图片时为什么结果模糊？

默认的 draw.CatmullRom 插值器虽平滑但容易过柔，尤其对小图缩放到大尺寸时明显失真。生产环境更推荐 draw.ApproxBiLinear（速度与质量平衡）或 draw.NearestNeighbor（像素画/图标类场景保锐度）。

• 缩放前务必检查源图是否为空或损坏，image.Decode 可能返回 nil, nil 或仅部分解码
• 目标尺寸需为正整数，负值或零会导致 draw.Draw panic
• 若源图是 paletted（如 GIF），需先转换为 *image.RGBA，否则缩放后颜色异常

src, _, _ := image.Decode(srcFile)
bounds := src.Bounds()
dst := image.NewRGBA(image.Rect(0, 0, 800, 600))
draw.ApproxBiLinear.Draw(dst, dst.Bounds(), src, bounds, draw.Over)

批量把 PNG 转成 JPEG 并控制质量用哪个库？

image/jpeg 自带 jpeg.Options{Quality: 85}，但注意：JPEG 不支持透明通道。遇到含 alpha 的 PNG，必须手动合成背景色，否则透明区域会变黑。

• 不要直接复用原图的 Bounds() 作为 JPEG 输出尺寸——某些 PNG 的 ColorModel() 是 color.NRGBA64Model，而 jpeg.Encode 只接受 color.YCbCrModel 或 color.RGBAModel
• 合成背景建议用 draw.Draw + image.Uniform，避免手写循环遍历像素
• 文件名后缀不自动更新，需显式替换 .png → .jpg

rgba := image.NewRGBA(src.Bounds())
draw.Draw(rgba, rgba.Bounds(), image.NewUniform(color.White), image.Point{}, draw.Src)
jpeg.Encode(dstFile, rgba, &jpeg.Options{Quality: 85})

处理 WebP 图片需要额外装什么依赖？

标准库不支持 WebP。golang.org/x/image/webp 仅提供解码，编码需靠 github.com/chai2010/webp（CGO 依赖 libwebp）或纯 Go 实现 github.com/h2non/bimg（底层调用 libvips，需系统预装）。

Docker Image Puller

使用 Python 脚本下载 Docker 镜像并打包为 tar 文件。用户说“下载镜像”“拉取镜像”“pull xxx”“帮我下载 nginx 镜像”等时触发。支持 SOCKS5 代理直连（推荐）和国内镜像站加速两种模式。

下载

• 若项目禁用 CGO，bimg 不可用，只能解码 WebP 后转成 PNG/JPEG 输出
• webp.Decode 返回的可能是 *image.YCbCr，转 JPEG 前需确认色彩模型兼容性
• Docker 部署时，记得在镜像中安装 libwebp-dev（Debian）或 libwebp（Alpine）

内存暴涨或 OOM 常见于哪些图片操作？

一张 4000×3000 的 24 位 PNG 解码后占约 36MB 内存（4000×3000×4 字节 RGBA）。并发处理多张图时极易触发 GC 压力或直接 OOM。

立即学习“go语言免费学习笔记（深入）”；

• 用 runtime/debug.ReadGCStats 监控 GC 频率，若每秒多次，说明图片对象未及时释放
• 避免在 HTTP handler 中直接 image.Decode 大图；应先用 io.LimitReader 控制上传体积上限
• 缩放后立即 dst = nil 并确保无闭包引用，防止逃逸到堆上长期驻留
• 考虑流式处理：用 jpeg.Encode 直接写入 http.ResponseWriter，跳过中间 *bytes.Buffer

Golang 图片处理没有“开箱即用”的万能方案，缩放质量、格式兼容、内存边界这三块最容易在线上突然出问题。别只测 100×100 的 demo 图。