应避免用os.readfile加载大图再解码，以防双倍内存占用oom；须改用os.open+io.limitreader限流，并优先调image.decodeconfig获取尺寸做前置校验。
用 image 标准库解码时，别直接读整个文件到内存
大图（比如 10MB+ 的 JPEG）用 os.ReadFile 加载再传给 image.Decode，会触发双倍内存占用：一次是原始字节，一次是解码后的 *image.RGBA。实际服务中容易 OOM。
- 改用
os.Open+io.LimitReader控制最大读取量，避免恶意超大文件耗尽内存 - 对 JPEG/PNG 等格式，优先用
image.DecodeConfig先读宽高和格式，做前置校验和尺寸限制 - 如果后续要缩放，直接在解码时传入
jpeg.Decode的jpeg.Options{Scale: 2}（Go 1.21+），跳过全尺寸解码
resize 库选 imaging 还是 bimg？
imaging 纯 Go 实现，易集成、无 CGO 依赖，但 CPU 密集型操作（如 Lanczos 重采样）比 bimg 慢 3–5 倍；bimg 是 libvips 绑定，性能强，但需部署 C 库且 Windows 支持弱。
- 内部服务、容器环境可控 → 用
bimg，注意设置BIMG_VIPS_CONCURRENCY环境变量控制线程数，默认是 CPU 核心数，高并发下可能争抢 - 边缘函数、FaaS 或 CI 构建受限 → 用
imaging，关闭imaging.Linear插值（默认），改用imaging.NearestNeighbor可提速 2x，画质损失可接受 - 两者都不要在 HTTP handler 里重复 new/resample 同一张图，缓存
*image.RGBA或 base64 编码结果更划算
并发处理图片时，runtime.GOMAXPROCS 不是调越高越好
图片解码/缩放本质是 CPU-bound，Go 调度器在高 GOMAXPROCS 下反而增加 goroutine 切换开销，尤其当单张图处理 >100ms 时，实测 4–8 核机器设为 4 比 runtime.NumCPU() 吞吐更高。
- 用
semaphore.NewWeighted(int64(concurrency))控制并发数，比简单chan struct{}更准——每张图权重可设为估算的 CPU 时间（如 2MP 图 ≈ 1，8MP 图 ≈ 3） - 避免在 goroutine 里调
http.DefaultClient.Do下载原图，DNS 解析和 TLS 握手会阻塞 M 线程；换成带连接池的 client，并复用http.Transport - 缩放后写入
bytes.Buffer再转[]byte，别用strings.Builder—— 它只优化 UTF-8 字符串，二进制图片数据会触发额外拷贝
WebP 输出时，libwebp 的 Quality 和 Lossless 怎么权衡
Go 标准库不支持 WebP 编码，必须依赖 golang.org/x/image/webp（纯 Go）或 bimg（libwebp）。前者质量差、编码慢；后者快但 Quality=80 和 Lossless=true 不能共存——libwebp 会静默忽略 Lossless。
- 要无损 → 必须显式设
Lossless: true，此时Quality参数无效，输出体积约是 JPEG 的 1.5–2 倍 - 要压缩率 → 设
Quality: 75（非 80），实测 75 比 80 小 15%，人眼难辨差异；低于 60 易出现块状伪影 - 别信文档里 “
Quality=100最高质量”，它只是关闭量化，不代表视觉保真，真要保真得用Lossless
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
