imgproxy 高性能图像处理代理

要解决什么问题

同一个源图在页面、移动端列表、内容系统里往往需要以多种尺寸和格式出现。商品图要缩到 400px 宽，封面要裁成 16:9，缩略图最好直接输出 WebP。常见做法是服务端预先生成一整套变体，或者让应用层去读写图像库。前者意味着新增一个尺寸就要重跑批处理，后者则把解码—变换—编码的开销塞进业务进程。

流量高峰期后者尤其麻烦。一张数兆的 PNG 在工作线程里解压、缩放、重新编码，很容易把请求链路拖慢，而且格式决策会散落在与图像无关的业务代码里。

技能如何工作

这个技能把 imgproxy 的能力暴露给 Agent：一个基于 Go 编写的高性能图像处理服务，核心思路是用 URL 描述变换，而不是写脚本。请求到达时服务端即时完成解码、变换、编码，并把结果缓存下来。

关键能力包括：

• 尺寸调整：按宽度、高度或比例缩放，通过 fit 策略控制裁剪与留白。
• 裁剪与定位：指定焦点坐标或锚点预设（如 gravity），在缩放后精准切出目标区域。
• 格式转换与优化：输出 WebP、AVIF、JPEG、PNG 等格式，并叠加压缩质量参数。
• 安全签名：用密钥对 URL 做 HMAC 签名，防止外部调用者随意构造高开销请求。

典型调用链路是：Agent 收到「生成 800px 宽的 WebP 封面」这类指令 → 拼出带签名的代理 URL → 交给下游下载或直接嵌入页面 → 首次请求触发即时处理，后续命中缓存。

适用边界与注意点

适合变换规则稳定、流量集中在 CDN 或反向代理层的媒体流水线。如果需要复杂合成、水印叠加、人脸识别后再裁切，这类纯变换代理覆盖不到，还得在上游或下游补一层处理。

签名密钥是部署凭据，泄露后任何人都能驱动服务器做图像处理。另外冷请求会直接消耗 CPU，并发的首次处理要加以限制，否则流量尖峰时容易把代理层打满。建议配合缓存层使用，让热点资源尽量命中缓存。