1. 为什么会想着自己部署一套 weserv-images1.1 一个真实的上线痛点先说一个我踩过的真实场景。当时手上有几个业务系统都在发图片商品图、文章封面、用户头像全堆在同一个静态文件服务里。前端为了适配不同尺寸后端一开始老老实实存了好几套副本原图、大图、中图、小图、缩略图命名规则还不统一。结果产品过来说要加一种列表页 4:3 裁切的样式后端就得重新跑一批图片导出任务光同步就花了大半天下次要调整又是另一轮体力活。后来我意识到这类需求本质上不是存储问题而是处理入口问题。图片该在哪个环节做缩放、裁切、转格式不应该绑死在业务代码和存储结构上而应该有一个独立、统一、可横向扩展的处理层。我当时想到的方案就是部署一个基于 Docker 的 weserv-images 服务把它作为图片处理的中间件插到现有架构里。这也是我今天想分享的完整过程。1.2 weserv-images 到底是干什么的weserv-images 是一个开源的图片处理代理服务核心引擎基于 libvips。它在整个链路里扮演的角色很单纯收到带处理参数的图片 URL 后先从上游源站把原图拉取过来按照 URL 上的参数实时缩放、裁剪、调质量、转格式然后把处理结果返回给调用方同时按规则缓存下来。本质上它把图片处理做成了一个独立的 HTTP 服务。你不需要在业务工程里引入任何图形库也不需要预生成一堆固定尺寸的图片只需要在请求图片的地方拼一个带参数的地址就能得到一张处理后的图。它支持 JPEG、PNG、WebP、AVIF、GIF还支持从 SVG、PDF 这类输入转成位图输出覆盖面很广。跟直接用某云的对象存储自带处理功能相比weserv-images 最大的价值是你可以完全私有化部署流量、存储、缓存都在自己手里处理逻辑不绑定特定厂商也不受厂商对格式和参数的限制。如果哪天某个云厂商对图片处理单独收费你也不会被账单调教。1.3 非侵入式三个字怎么理解这个项目标题里非侵入式是最关键的一个词。所谓非侵入就是不需要改动原有系统的内部逻辑源站的目录结构不用动后端存储不用动数据库里图片 URL 的归属字段也不用动。你要做的只是把图片 URL 的地址前缀从原来的静态域名换到这个 weserv-images 实例或者在原前缀后面追加处理参数。用一个生活化的比喻它就像加在自来水管道上的一个过滤净化器。水管还是原来的水管用户接到嘴里的水也不会改变他的使用方式只是中间多了一道按需净化的工序。如果哪天不需要了拆掉这个净化器水管一接回原样业务完全不受影响。这种低耦合的属性让它特别适合做中间件因为中间件本身的价值不是取代业务系统而是为业务系统提供可选择的增强能力。要提醒一点非侵入并不等于零配置。域名白名单、缓存目录、资源限制这些还是得提前想好不然上线后调整会非常被动。后面我会把这部分拿出来细讲。2. 整体设计中间件应该放在哪个位置2.1 选型依据为什么不用对象存储自带处理能力如果你现在的图片已经放在某云对象存储上大概率会想直接用云厂商自带的图片处理不就行了为什么还要自己折腾一个服务这个选择确实需要对比清楚。我整理了一张表把我当时比较的结果放在这里对比项对象存储自带处理自建 weserv-images格式支持各家策略不一致AVIF/WebP 不一定齐全libvips 支持格式较全输出可任意组合资源消耗按处理次数额外计费费用跟调用量线性增长只用花自己服务器资源带宽和CPU可控私有化不支持图片要么公网要么走内网网关可以完全内网化仅对应用网关开放扩展性处理参数通常绑定某云平台URL 协议自由可挂 CDN、可加 Nginx 层迁移成本换了云厂商拼接规则全部重写服务自持前端只认形态一致的 URL还有一个很容易忽略的点云厂商自带的图片处理规则一般是存储桶 样式模板改一个样式模板往往有生效延迟。而 weserv-images 是请求级别的实时参数改前端代码的拼接规则就能立即生效不需要等后台模板刷新。对于需要频繁 A/B 测试不同图片样式的团队来说这个灵活性很值钱。如果你原本不是用对象存储而是自己 Nginx 托管的静态文件那自建处理服务基本是唯一选项。这种情况下 weserv-images 不但能处理还能兼任一层源站代理缓存和回源都替你管了。2.2 三种常见接入架构根据你的原图在哪儿、流量从哪儿来我建议从下面三种架构里选一种架构 A外部 CDN - weserv-images - 源站适合图片访问量比较大的公网生产环境。CDN 负责边缘缓存和加速weserv-images 作为回源节点只要 CDN 缓存未命中就把带参数的请求转发给它处理。这种架构下不同尺寸的图片在 CDN 上会形成不同的缓存键比如?w100和?w500是两张缓存实体互不污染。架构 B应用 Nginx - weserv-images - 源站适合中小流量或者内网环境。Nginx 只做统一入口和日志记录把/img/前缀的请求代理给 weserv-images。这种架构下后端应用完全不用感知处理服务的存在前端拿到的是一个统一的图片地址。架构 Cweserv-images 直连适合内部工具、后台管理系统、运营平台。没有 CDN 也没有外部网关只有内网 DNS 和端口访问。优点是简单缺点是当业务量上来后每一个实时处理请求都会打到源站缓存压力会大一些。我当时实际用的是架构 B后面再加一层 CDN 变成 A 的变体。核心思路是把 weserv-images 当作处理和缓存一体的一级节点业务侧零改动。2.3 这个中间件给架构带来的实际变化引入这个中间件之后最直观的变化是图片出口统一了。以前不同业务各自实现缩略图方案有的用 CSS 硬缩有的在后端调 graphics 库有的干脆让前端加载原图再裁剪加载慢不说还白白浪费流量。统一走 weserv-images 后所有图片请求都过同一个处理逻辑格式压缩、缓存策略、域名规则都收敛到一个点。第二个变化是格式降级变得非常容易。以前想给图片上 WebP得先确认各浏览器兼容再额外生成 WebP 文件。现在只需要在 URL 里指定outputwebp或者让服务根据请求自动判断前端完全不用管浏览器兼容问题。类似这样针对特定场景做格式适配在旧架构里非常折腾在中间件架构里就是一行参数的事。第三个变化是带宽成本下降。weserv-images 处理完的图片默认会做质量压缩和适当的尺寸限制不再是原图直出。实测下来同等流量的图片体积有时候能降 40% 以上带来的效果是页面加载速度提升服务器出口带宽压力也小了很多。所以我的观点是这种中间件不是简单替换后端生成缩略图的功能而是把整个图片流量的出口位置重新做了规划。规划好了后面做缓存命中、灰度发布、安全限制都会顺很多。3. Docker 部署从拉镜像到跑起来3.1 先拿镜像再定版本weserv-images 官方发布的镜像在 GitHub Container Registry镜像名是ghcr.io/weserv/images。旧版本也存在 Docker Hub 的weserv/images但以我最近的实践新项目直接使用 ghcr 上的镜像更合适更新及时 arm64 和 amd64 架构都有对应版本在云主机或者 ARM 开发板上都能跑。拉取镜像的命令很简单docker pull ghcr.io/weserv/images:latest我不建议在生产环境直接追 latest 标签因为服务毕竟面向线上流量版本升级可能带来参数行为的细微变化。更稳妥的做法是拉一个固定版本号比如docker pull ghcr.io/weserv/images:7.0.0这种以仓库实际发布标签为准先在测试环境跑一段时间确认没问题再升级生产。这个习惯跟任何中间件都一样越稳定的组件越不要频繁动版本源。3.2 最简部署一条 docker run 命令如果你只是想在本地快速验证一把一条命令就够了。docker run -d \ --name weserv \ -p 8080:8080 \ --restart unless-stopped \ ghcr.io/weserv/images:latest跑起来之后用一个最简单的请求测试curl -I http://localhost:8080/?urlexample.com/photo.jpgw200如果返回200 OK说明服务已经在工作了。这里要留意?url参数必须填能公网或内网访问到的地址因为 weserv-images 是服务端回源拉图不是浏览器直连。这条命令能跑但只是能用级别还缺少三个关键配置域名白名单、缓存目录、日志位置。如果不加白名单服务允许处理任意域名的图片一旦端口暴露到公网就会被人当成免费图片代理白白消耗你的带宽。所以下面这个 Compose 配置才是生产级起点。3.3 推荐的生产级 Compose 编排我习惯用 Docker Compose 管理这类有状态服务因为它能把环境变量、数据卷、资源限制都写进一个文件换机器部署时直接原样搬走。下面是我线上环境的一个精简版本version: 3.8 services: weserv: image: ghcr.io/weserv/images:7.0.0 container_name: weserv-images restart: unless-stopped ports: - 127.0.0.1:8080:8080 volumes: - ./data/cache:/var/cache/weserv - ./data/logs:/var/log/weserv environment: WESERV_CACHE: /var/cache/weserv WESERV_LOG: /var/log/weserv WESERV_ALLOWED_DOMAINS: static.example.com,cdn.example.com WESERV_MAX_BYTES: 21915240 WESERV_UA: Weserv/2.0 (https://example.com/weserv-bot) healthcheck: test: [CMD, curl, -f, http://localhost:8080/] interval: 30s timeout: 5s retries: 3 deploy: resources: limits: memory: 1024M这里有几个写配置时容易踩坑的地方第一端口只绑定到本机回环地址也就是127.0.0.1:8080:8080不让外部直接访问容器端口。对外统一由 Nginx 或 CDN 回源这也是中间件安全设计的一部分。第二环境变量前缀是WESERV_后面跟配置名。不同版本可能有些变量名差异动手前先到官方仓库 README 里确认一遍。特别是WESERV_ALLOWED_DOMAINS多个域名用英文逗号分隔中间不要带空格。第三WESERV_MAX_BYTES默认值是约 22MB指的是单张原图最大允许拉取的大小。这个值需要根据你的源站图片体积调整设置太小会把正常大图截断设置太大会让内存压力变大。启动命令是老一套docker compose up -d启动后看日志确认没有报错docker compose logs -f weserv看到类似listening on 0.0.0.0:8080的日志服务就算正常了。再把这个例子中的缓存目录、日志目录换成你自己的路径就能进入参数调试阶段。4. 图片处理参数与使用细节4.1 URL 格式与域名白名单weserv-images 支持两种取图方式。最推荐的是查询参数方式所有信息都放在 query 里http://localhost:8080/?urlstatic.example.com/path/to/image.jpgw400h300fitcover另一种是路径方式域名直接跟在服务地址后面http://localhost:8080/static.example.com/path/to/image.jpg?w400关于这两种方式我的经验是优先用查询参数方式。因为它不需要解析路径也不容易被意外反转义更重要的是如果原图 URL 本身带 query 参数比如image.jpg?v123路径方式会把参数混在一起非常容易出错。用查询参数方式时原图地址需要做 URL 编码把://和?等特殊字符编码掉才能放在参数值里。这里就涉及域名白名单的重要性。WESERV_ALLOWED_DOMAINS配置了允许处理哪些域名下的图片不在名单里的域名会被拒绝。公网环境下这个必须配置否则你的服务就是一张万能图片代理票谁都能拿它去拉外部任意图片既耗流量又可能卷入版权问题。内网环境下建议仍然配置至少把归属明确的几个业务域名写进去宁可后续增加也不要一开始就全放行。4.2 缩放、裁剪、格式转换怎么用weserv-images 的参数体系设计得比较规整使用思路上和 CSS 的 object-fit 有点类似理解一组概念就能覆盖大部分场景。我把最常用的参数整理成了下表参数作用示例w输出宽度pxw400h输出高度pxh300fit缩放模式cover、contain、inside、outsidefitcovercrop自定义裁剪区域或焦点crop0,0,400,300output输出格式jpg、png、webp、avif、gifoutputwebpq图片质量范围 1-100q80sharpen锐化强度sharpen3blur高斯模糊程度blur5filter滤镜greyscale、sepia 等filtergreyscalerotate旋转角度rotate90filename下载文件名filenamecover.jpg举两个实际的例子。列表页常见的方图缩略图可以用这个参数组合http://localhost:8080/?urlstatic.example.com/product/a.jpgw300h300fitcoveroutputwebpq80它会先把图片按比例放大或缩小到能覆盖 300x300 的区域然后居中裁剪成一张 300x300 的方图输出 WebP 格式质量压到 80。这个用法跟object-fit: cover语义上非常接近前端同事几乎零学习成本。再来一个适合背景图的模糊渐变效果http://localhost:8080/?urlstatic.example.com/photo/b.jpgw1200blur15q70输出的是一张 1200px 宽、带 15 级模糊的图适合做页面首屏的渐变背景。以前这种效果要么后端单独生成一张图要么前端用 canvas 处理现在一个 URL 参数搞定。实操中我提醒两点第一w或h只填一个时另一个维度会按原图比例等比缩放这符合大多数缩略图的预期不用额外指定fit第二fitcover和fitcontain的选择要谨慎前者会裁剪内容后者会在容器内留白两种效果在视觉上差异很大一定要前端确认清楚再定参数。4.3 原图拉取策略UA、超时和大小限制weserv-images 处理链路的第一步是服务端去源站拉原图。这个环节有三个配置直接影响成功率请求 UA、超时时间、大小限制。很多源站的防爬策略对默认 UA 会直接拒绝要么返回 403要么跳转验证页面。遇到这类情况需要给 weserv-images 设置一个来源明确的 UA比如在环境变量里配WESERV_UAMozilla/5.0 (compatible; your-unique-ua/1.0)但也要避免伪装成浏览器 UA因为部分 CDN 服务商对浏览器 UA 的请求处理策略和普通客户端不同反而会触发更严格的风控。最稳妥的是用一个能标识你服务身份的 UA 字符串。超时配置这块我建议设置成快速失败宁可重试的策略。如果源站响应慢weserv-images 长时间占着一个处理线程资源很快会被拖垮。具体超时秒数可以根据源站实测延迟来定一般 5 到 10 秒比较合理。大小限制也值得单独说一说。即使源站图片单张可能达到 20MB也不建议把WESERV_MAX_BYTES调到太大因为 weserv-images 在拉取图片后要解码再处理内存峰值和图像尺寸强相关。如果是超大宽高比的图片即使文件体积不大解码出来也可能撑爆内存。这类问题后面会单独展开这里先埋个伏笔。4.4 缓存机制命中率决定了服务上限weserv-images 的缓存设计比较朴素但有效它以处理请求和参数为键把处理结果缓存到本地磁盘。相同 URL 的第二次请求直接从缓存里读文件返回不再回源拉原图也不重复执行处理逻辑。缓存命中率是衡量这个中间件是否值得部署的核心指标。如果业务图片是高频固定参数比如文章列表缩略图固定 200px命中率能达到很高的水平处理服务的 CPU 占用会非常低。相反如果每次请求都拼不同的随机参数比如把质量参数调成 73、75、77 这种无规律变化缓存就形同虚设每个请求都会打满全链路。所以我在内部推广使用时一直强调图片参数必须收敛不能用乱数生成器构造 URL。前端要做的是在几个固定尺寸模板里做选择而不是每次都发明一种新尺寸。这个道理和 CDN 缓存一样流量越大参数收敛带来的收益越明显。缓存文件写到宿主机挂载目录后还需要安排定期清理策略。我一般会在 Nginx 层对图片设置合理的 Cache-Control 过期时间同时在服务配置里根据磁盘空间做容量限制。不清理的话缓存目录会随着图片种类增多不断膨胀最终有可能把数据盘写满。5. 业务集成把处理服务嵌入现有体系5.1 Nginx 反向代理接入既然 weserv-images 定位是中间件对外最好不直接暴露业务端口而是用 Nginx 做统一入口。这样不管是记录访问日志、设置请求体大小、还是叠加鉴权都在一个熟悉的边界上完成。下面是我在 Nginx 里用的一个基础配置片段server { listen 80; server_name img.example.com; access_log /var/log/nginx/img.access.log; location / { proxy_pass http://127.0.0.1:8080; proxy_set_header Host $host; proxy_set_header X-Forwarded-For $remote_addr; proxy_read_timeout 15s; proxy_send_timeout 15s; add_header Cache-Control public, max-age2592000; } }这个配置只做了两件事把/路径请求代理给本机 8080 端口的 weserv-images 容器同时给所有图片响应加一个 30 天的浏览器缓存头。图片是强缓存友好的资源只要 URL 里带不同参数缓存键就不同所以给一个长过期时间很安全。如果你的图片处理参数总是变但域名不变我建议在 Nginx 层把带参数的请求统一加一层 URL 校验太长的请求直接拒绝避免生成超大尺寸图片。比如限制w和h的最大值这个可以靠 Nginx 的if判断实现更复杂的校验可以走 Lua 或者 OpenResty。这里有一个容易忽略的细节反向代理的超时时间必须大于 weserv-images 后端处理耗时否则用户在浏览器里会看到 504 错误。特别是首次回源拉图如果源站比较慢Nginx 默认的 60 秒可能不够我习惯把proxy_read_timeout设置成 15 秒到 30 秒之间既不拖太久也不会在慢源站场景下误杀。5.2 前端图片 URL 改造策略接入中间件之后前端改动其实很小核心就是把图片地址的 host 换掉、拼上处理参数。原来可能是img srchttps://static.example.com/logo.png改造后变成img srchttps://img.example.com/?urlstatic.example.com/logo.pngw200h200fitcoveroutputwebp但我不建议到处硬编码这种 URL而是封装成一个统一方法或组件。以 Vue 为例可以抽一个简单的函数function buildImageUrl(src, { width, height, fit cover, format webp, quality 80 }) { const params new URLSearchParams({ url: src.replace(/^https?:\/\//, ), w: width, h: height, fit, q: quality }); if (format) params.set(output, format); return https://img.example.com/?${params.toString()}; }这样业务侧只需要关心我要一张什么尺寸的图不需要关心中间件地址、参数语义也不需要在每个页面重复拼接 URL。后续如果要换 CDN、调参数模板只要改这一个地方。还有一个很实用的经验如果你觉得改历史存量代码成本高可以在 Nginx 层根据 URL 前缀做自动改写。比如把所有/static/开头的图片请求在 Nginx 里重写为带w400的新 URL。这样存量页面基本不用改只把 CSS 或 CDN 上的图片前缀换一下就行。这种做法虽然带点黑魔法属性但用于过渡期非常合适能让改造周期从几周缩短到几天。5.3 给 CDN 做回源扩大缓存覆盖面如果你的图片访问量已经到一定规模建议在 weserv-images 前面再套一层 CDN。CDN 负责将边缘节点上缓存好的图片直接返回给用户只有缓存未命中的请求才回源到 weserv-images进一步压缩后端处理压力。接入 CDN 时要注意一个关键点CDN 的缓存键要包含查询参数。很多 CDN 默认忽略 query string 或者把它们全部纳入缓存键前者会导致不同尺寸的图片返回同一张错图后者会导致缓存碎片太多、命中率反而下降。我的做法是开启 CDN 的参数过滤或忽略无用参数功能只让url、w、h、fit、output、q这几个参与缓存键计算其他无关参数一律忽略。这样既保证不同处理方式能区分出独立缓存又避免无意义参数污染缓存空间。另外上线新尺寸模板时可以主动调用一遍 CDN 预热接口。不需要把所有图片都预热只需要把首页、热门文章、商品列表等最高频的资源做预热让第一批用户访问时不会都扎在回源上。实测下来预热的收益非常直接高峰期 502 的概率能明显降下来。6. 常见问题与排查技巧实录6.1 域名白名单导致的黑图/403现象浏览器里打开处理后的图片地址直接显示 403 或者返回空内容。检查 weserv-images 日志能看到类似domain not allowed的报错。原因绝大多数情况是WESERV_ALLOWED_DOMAINS没有包含请求里的原图域名或者配置时写了带http://前缀的域名匹配不上。排查先在宿主机上用 curl 直接请求一下 weserv-images 内部接口不经过 Nginxcurl -I http://127.0.0.1:8080/?urlstatic.example.com/test.jpgw100如果这个请求也 403基本可以确定是白名单问题。去 Compose 文件里看环境变量的值确保域名和回源 URL 里的域名完全一致不要带协议头不要带路径。6.2 大图片导致内存与超时现象处理某些大图时日志显示超时或容器直接 OOMDocker 把容器杀掉了。原因图片的像素总量太大。比如一张 8000x6000 的 JPEG即使文件只有几 MB解码后的原始位图体积也接近 200MB加上缩放过程的中间内存很容易超过容器限制。解决两层配合。第一层在 Compose 里给容器设定内存上限防止单张图把整个宿主机的内存拖垮第二层在应用层限制w和h的最大值让任何处理结果都不允许超过某个分辨率上限。如果业务上确实要处理超大原图可以把WESERV_MAX_BYTES适当调大同时给容器扩内存但不要无上限地放开。我踩过的坑是一开始只限制文件体积没限制像素上限结果一张 1MB 的超大像素图把内存打满。所以我的建议是把文件体积限制和图片分辨率限制看成两件事分别设限。6.3 缓存目录权限问题现象容器启动后访问图片一直报内部错误日志里能看到Permission denied或者无法写入缓存目录的提示。原因我把缓存目录通过 volume 挂载到宿主机目录之后宿主机目录的属主是 root容器内的进程没有写权限。解决在宿主机上先建好目录然后给写权限或者直接把目录属主改成容器内运行用户的 UID。习惯做法mkdir -p ./data/cache ./data/logs chown -R 1000:1000 ./data如果是 Mac/Windows 的 Docker Desktop挂载目录还有文件读写性能问题。调试用途可以接受生产环境我建议用 Docker 命名卷named volume性能比 bind mount 更稳定。6.4 新格式在旧浏览器里的兼容性问题现象把outputwebp或outputavif作为默认参数后一部分老浏览器显示不出图片。这种问题通常不在服务端而在客户端格式支持上。解决我的做法是服务端按需降级CDN 层做协商。具体来说给一个不带output参数的默认版本让 weserv-images 根据请求的Accept头判断是否要输出 WebP 或 AVIF。设置完成后旧浏览器拿到的是 JPEG现代浏览器拿到的是 WebP两者互不影响。这台中间件的定位是处理入口格式协商这种规则放到这个入口来做远比散落在各业务代码里要好维护。我整理了一张速查表可以帮你快速定位问题现象可能原因排查手段403 / 空白域名不在白名单检查WESERV_ALLOWED_DOMAINS504 超时源站回源慢或处理超时调整超时、测源站延迟内存溢出原图像素超大限制 w/h 和 MAX_BYTES写缓存失败挂载目录无权限改宿主机目录属主部分浏览器白图格式不支持按 Accept 头自动降级服务启动失败端口冲突或环境变量错误看 docker compose logs这些坑我基本都在上线初期踩过一遍。最浪费时间的是域名白名单问题因为它报错信息往往不直观。所以这里再强调一遍上线前务必将所有要用到的回源域名一次性列全写进白名单包括测试域名不然很容易在灰度阶段被一块黑图挡住。7. 监控、日志与安全加固7.1 看访问日志和缓存命中情况weserv-images 本身没有自带复杂的监控面板但这不影响做基本观测。通过 Docker 容器的 stdout 日志可以看到每一次请求的处理结果、耗时和状态码。把这些日志交给日志采集系统或者简单转发到文件就能统计出几个关键指标每秒请求数、平均处理耗时、4xx/5xx 比例。我还习惯在 Nginx 层记录一层访问日志因为 Nginx 日志里包含用户真实的 IP 和请求 UA对排查问题更直接。通过对比 Nginx 日志和容器日志可以判断瓶颈在反向代理层还是处理层。如果服务已经跑起来想知道缓存命中情况可以手动在服务器上用curl -I连续请求两次同一个图片地址第一次通常显示源站回源耗时第二次应该明显变快说明缓存生效了。想要更精确的数据可以开发一个小脚本定期扫描缓存目录的文件数量与总大小设定阈值触发清理告警。7.2 安全加固清单中间件一旦被滥用轻则流量被盗刷重则变成攻击别人的跳板所以安全列表必须给它过一遍限制来源域名。这个前面反复提过是第一个要上的锁。公网环境下绝不能留白。限制处理参数。在 Nginx 层检查w、h参数是否为合法数字且不超过上限。例如超过 4000px 的任何请求直接返回 422 或 404。这部分逻辑简单但有效能防住有人故意用w99999生成超大图片拖垮资源。限制可输出格式。不是所有场景都需要 AVIF、PDF 输出。如果业务只用 JPEG、PNG、WebP就在外层校验output参数其他格式一律不接受。这样既能减少内存开销也能防止恶意请求把服务当格式转换器使用。内网隔离。对外提供服务的入口只能是 Nginx 或 CDNcontainer 端口只绑定回环地址。如果源站在内网中间件也部署在内网那整个链路不出公网风险最小。加一层基础鉴权。即使是内部服务也建议在 Nginx 层加 Basic Auth 或者按来源 IP 限制避免同一局域网内任何人都能拼图片 URL 消耗资源。这些加固手段不复杂但每一项都对应一个具体的滥用场景。我见过不少团队把图片处理服务裸奔到公网最后被刷了几百 GB 流量才发现。这种事发生之后厂商的流量账单会立刻教你做人所以还是提前把准备工作做踏实比较好。最后再分享一个我个人一直保留的习惯新服务上线后前两周每天看一次访问日志和资源监控把请求量、处理耗时、缓存命中率的变化记下来。中间件这类服务前期数据往往能暴露出很多你规划时没想到的流量模式早发现早调整等业务稳定之后基本就不用再操心了。