0. 先问一个问题：这张图需不需要压缩？#

原图 1.9MB，压缩目标 2MB——原图本身已经达标。如果“压缩版”的语义只是“≤2MB、≤4096px 的可分发版本”，那这次上传的正确做法是直接复用原图，压缩耗时应该是 0。

建议加一个前置短路：

Go

1
if origSize <= targetBytes && maxSide(origW, origH) <= maxDim && isWebFriendly(format) {
2
    return original, nil // 跳过压缩
3
}

这一条改动 5 行，覆盖大量手机/相机直出的 JPEG。如果产品语义确实要求统一转成 WebP/AVIF，再往下看。

1. 换编码器：照片用有损，不要用 nativewebp#

nativewebp 只有 VP8L 无损，对照片天然 ~1 byte/px，怎么调都不会好。方案按改动量：

按源格式分流：image/jpeg、HEIC 等照片走有损；PNG/截图（色彩数少）才走无损。

2. 重写尺寸/质量决策：一次估准，最多重试 2 次#

核心思路：有损编码下，输出大小 ≈ 像素数 × bpp，bpp 在固定质量下很稳定，所以第一次编码结果就能直接算出目标尺寸。同时先降质量再缩图，分辨率比质量值钱得多。

Go

1
func CompressToTarget(src image.Image, maxDim int, target int) ([]byte, error) {
2
    img := fitWithin(src, maxDim) // 用 BiLinear/Box，别用 CatmullRom 缩 11MP
3

4
    qualities := []int{85, 75, 65}
5
    for round := 0; round < 3; round++ {
6
        for _, q := range qualities {
7
            buf := encodeLossy(img, q)
8
            if buf.Len() <= target {
9
                return buf.Bytes(), nil
10
            }
11
            // 质量降到 65 仍超标才缩图；跳出去按比例缩
12
            if q == qualities[len(qualities)-1] {
13
                ratio := math.Sqrt(float64(target)/float64(buf.Len())) * 0.92
14
                img = scale(img, ratio) // 不设 0.55 下限，最多钳一个 0.25 防极端
15
            }
16
        }
17
    }
18
    return nil, errCannotFit
19
}

同时修掉原逻辑的两个问题：

• 删掉 BestCompression→Default→BestSpeed 的降级重试。无论有损无损，同一尺寸下更低压缩级别只会更大。如果保留无损路径，就只试最高级别一次，超标直接进缩图。
• 去掉 max(0.55, ratio) 钳制。这个下限的初衷大概是怕一次缩太狠，但 0.92 安全系数已经够了；真怕就用 0.25，并且缩完第一次就应该命中。

预期：11MP 照片 → 缩到 4096px（0.2s）→ q85 编码（0.3s）→ 大概率 1.5–2.5MB，最坏再编一次 q75，总耗时 < 1.5s。

3. 检查隐藏成本：解码与缩放#

看日志里每轮 15–18 秒，其中不一定全是编码。确认：

• 原图只解码一次，CompressToWebP 各轮复用同一个 image.Image，而不是每轮 image.Decode。
• 缩放算法：golang.org/x/image/draw 的 CatmullRom 缩 11MP 要 2–4 秒。改成 ApproxBiLinear，或先按整数倍 Box 缩到 2 倍目标、再 BiLinear 到最终尺寸，视觉差别很小，速度差 10 倍。
• 像素格式：image.YCbCr 直接喂给编码器会触发逐像素转换，先转 *image.RGBA/*image.NRGBA 一次，后续所有编码复用。

4. 缩略图 3.76s：大概率是 wasm 冷启动，不是 libaom 慢#

gen2brain/avif 是 libavif+aom 编译成 WebAssembly 后用 wazero 跑的，第一次调用要编译 wasm 模块，通常 1–3 秒，之后才是真正的编码。三个选法：

1. 最简单：缩略图改用 JPEG（q80，512px 约 30–60KB）或 WebP，512px 的 JPEG 编码只要几毫秒。缩略图的体积收益本来就小，AVIF 在这里不值。
2. 坚持 AVIF：进程启动时后台 warmup 一次（编一张 1×1），把 wasm 编译成本移出上传链路；并确认没有每次上传都重新 Encode 初始化。
3. 顺带检查缩略图是不是从 11MP 用 CatmullRom 直接缩到 512——这一步本身就可能 1–2 秒。改成从压缩版（4096px）再缩，或用上面说的两段式缩放。

5. 并发化上传链路#

现在是串行：压缩 → 传原图 → 编缩略图 → 传缩略图 → register。三条数据流互不依赖：

text

1
decode ─┬─ upload original (0.7s)
2
        ├─ compress → upload compressed
3
        └─ thumbnail → upload thumb (0.4s)
4
        └───────────── all done ──→ register

用 errgroup 并发，总耗时变成 max(三条) + register。压缩降到 1.5s 后，客户端侧总时间 ≈ 1.5–2s。

6. Register 3.7s：服务器端单独排查#

两次都 3.7–4.1s、与图片大小无关，说明是固定成本，典型嫌疑：

• 事务里同步做了重活：解析 EXIF、生成派生数据、调外部服务、对对象存储做 HEAD/校验。
• 等待某个锁或串行队列。
• Postgres 侧：缺索引导致的全表扫描、synchronous_commit + 慢盘、连接池耗尽等待。

处理方式：给 register handler 加分段计时日志定位，然后把非必要工作改成 写行 + 入队异步处理，立即返回 202。目标 < 200ms。

预期效果#

建议实施顺序：先做 0 和 2（纯逻辑修改，半天内完成，立即去掉 60 秒浪费），再做 1 和 4（换编码器），5 和 6 可以并行由服务端同学推进。