去年做内容社区项目的时候，审核后台的缩略图被运营放大一看全是马赛克，用户上传的截图、老照片、商品细节图，糊得没法看。当时产品经理跑来问能不能加个"一键变清晰"的按钮，我第一反应是自研超分模型，算了一下显卡成本和推理延迟，直接劝退。后来走的路子是在Java后端接一个图片清晰度增强API，把增强能力交给云端，业务侧只负责传图和收图。
这篇文章就是当时那套东西的完整复盘。适合谁看？手上有个Java服务、需要给图片做清晰度提升但又不想自己训模型的开发者；也适合刚接触云API调用、被access_token和base64来回折腾过的同学。我会把鉴权、传图、参数调优、超时重试、计费坑这些东西按实际落地的顺序拆开讲，代码可以直接抄，思路可以直接搬。需要先说明一点：市面上几家云厂商都有这类"图像清晰度增强"接口，参数名和路径各有差异，下文用通用写法描述，具体字段以你手上那份文档为准，但整体链路是相通的。
1. 为什么把清晰度增强放到云端而不是本地做
1.1 业务里那些"糊图"的真实来源
先弄清楚糊图是怎么来的，这决定了你该选哪种增强策略。我统计过我们平台三个月的低质图片，大致分四类：用户端压缩上传（前端为了省流量把1080P压成480P再传）、历史数据迁移（早期存储的缩略图只有一种尺寸，现在要在大屏上展示）、二次截图（用户把截图再截图，经过两轮JPEG压缩，块效应明显）、扫描件和老照片（本身分辨率低，还带噪点）。
这四类的修复难度完全不一样。第一类和第二类是"有信息但被压掉了"，增强模型还能救回来一部分；第三类块效应严重，过度增强会把压缩伪影也放大，看着更脏；第四类需要先去噪再锐化，顺序错了就是一片糊。你得先分类，再决定参数，而不是所有图丢进去跑同一个配置。我在项目里给上传入口加了一个简单的判断：短边小于800px且文件小于100KB的走"强力增强"，正常尺寸的走"轻度增强"，扫描件单独走一条带去噪的链路。
1.2 自研模型和调接口的成本账
很多同学的第一反应是"我自己跑个超分模型不香吗"。我算过一笔账：一张1080P的图，在中端GPU上跑一次Real-ESRGAN类的模型大概200~500ms，按每天10万张算，需要至少2~3张卡常驻才能扛住峰值，加上模型部署、版本管理、故障转移，投入不小。而调云端接口，成本是按次计费，量小的时候几乎零成本，量大时再谈折扣，弹性好很多。
真正让我下决心的是运维复杂度。模型服务挂了要人修，显存爆了要人查，推理结果不对要人调；而API挂了，通常换个可用区或者降级到"不增强直接返回原图"就过去了，业务不会整个卡死。当然代价也有：网络延迟不可控、单张图有大小上限、批量处理会撞QPS限制，这几条后面都会详细讲怎么绕。
提示：如果你的业务对图片隐私极其敏感（比如证件、医疗影像），先确认清楚数据合规要求再决定是否走云端，这一点没有商量余地。
1.3 这类接口到底能干什么、不能干什么
必须先把预期拉正，不然上线后被业务方追着问"为什么还是糊"很难受。图像清晰度增强接口做的事情，本质上是基于先验知识重建高频细节——它能补出纹理、锐化边缘、去掉一部分压缩噪点，让图"看起来更清楚"，但它不能凭空创造原本不存在的真实信息。一张20×20的人脸缩略图，增强后能看清轮廓，但指望看清睫毛是不可能的。
实测下来能力边界大致是这样：
| 场景 | 增强效果 | 注意事项 |
|---|---|---|
| 轻微压缩的低清图 | 明显改善，边缘干净 | 增强强度调低，避免过锐 |
| 严重块效应的截图 | 中等改善，伪影减轻 | 不要叠加多次增强 |
| 老照片、扫描件 | 中等改善，噪点减少 | 需配合去噪参数 |
| 文字截图 | 改善明显，笔画更实 | 字体过小时仍不可读 |
| 极小尺寸缩略图 | 改善有限 | 建议先确认是否有原图 |
把这张表贴到需求文档里，能省掉后面很多扯皮。
2. 接入前必须搞定的鉴权和依赖准备
2.1 密钥体系与access_token的最小闭环
大多数云平台的调用链路是两层：长期的API Key / Secret Key换短期的access_token，再用access_token去调具体接口。为什么要多这一层？因为长期密钥一旦泄露风险极大，而token有有效期（常见30天），泄露影响可控，同时平台侧也能基于token做更细的配额和权限控制。
踩过的坑在这里：很多人把Secret Key直接写死在代码里提交到了代码仓库。我接手过一个项目，密钥硬编码在常量类里，仓库还是公开的，发现的时候已经跑了小半年。正确做法是走环境变量或者配置中心，最低限度也要放在不参与版本控制的配置文件里，并且定期轮换。
换取token的请求，本质就是一个OAuth的client_credentials流程，用表单方式POST上去：
// 换取access_token，注意参数是 application/x-www-form-urlencoded public String fetchAccessToken(String apiKey, String secretKey) throws IOException { OkHttpClient client = new OkHttpClient.Builder() .connectTimeout(5, TimeUnit.SECONDS) .readTimeout(10, TimeUnit.SECONDS) .build(); RequestBody body = new FormBody.Builder() .add("grant_type", "client_credentials") .add("client_id", apiKey) .add("client_secret", secretKey) .build(); Request request = new Request.Builder() .url("https://{your-api-host}/oauth/2.0/token") .post(body) .build(); try (Response response = client.newCall(request).execute()) { if (!response.isSuccessful() || response.body() == null) { throw new IOException("换取token失败，HTTP状态: " + response.code()); } String json = response.body().string(); return JsonPath.read(json, "$.access_token"); } }这里有个细节：返回体里通常还有expires_in字段，单位是秒。不要把它当成摆设，后面缓存过期时间就要靠它算。
2.2 token缓存：比"能不能拿到"更容易出问题的是"拿了几次"
如果每次调增强接口都去换一次token，会出现两个后果：一是多一次网络往返，整体耗时翻倍；二是容易触发平台的token获取频率限制，尤其是多实例部署的时候，10个Pod各换各的，量一下子就上去了。
我的做法是进程内缓存加提前刷新：
public class TokenHolder { private static volatile String token; private static volatile long expireAt; // 毫秒时间戳 public static String get() { // 提前5分钟刷新，避免临界点拿到即将过期的token if (token == null || System.currentTimeMillis() > expireAt - 5 * 60 * 1000L) { synchronized (TokenHolder.class) { if (token == null || System.currentTimeMillis() > expireAt - 5 * 60 * 1000L) { // 真实项目里这里应调用上面的 fetchAccessToken TokenResult result = refreshFromRemote(); token = result.getAccessToken(); expireAt = System.currentTimeMillis() + result.getExpiresIn() * 1000L; } } } return token; } }为什么要提前5分钟刷新而不是到期再换？因为从你判断"还有10秒过期"到请求真正到达服务端，中间隔着网络延迟和排队，很可能到了服务端token已经失效，接口返回鉴权失败。提前量就是给这段不确定性留的缓冲。
还有一个容易忽略的点：如果服务是多实例部署，每个实例各自缓存token，那就是N份token。大多数平台允许这样做，但如果你想省，可以把token放到Redis里做共享缓存，代价是多一次Redis往返（毫秒级，通常划算）。
2.3 HTTP客户端选型与base64的体积陷阱
Java这边可选的有三种：JDK自带的HttpClient（Java 11+）、OkHttp、Apache HttpClient。我选OkHttp，理由是连接池管理成熟、超时配置直观、multipart和表单构造都方便，而且体积不大。如果你的项目已经用了Spring的RestTemplate或者WebClient，也可以直接用，没必要为了一个接口引入新依赖。
真正要小心的是base64编码的体积膨胀。一段二进制数据经过base64编码后，体积大约是原来的4/3倍，也就是33%的膨胀。一张3MB的JPEG，base64之后接近4MB，如果接口对请求体总大小有限制（很多平台限制在4MB或7MB），很容易踩线。
我给的建议是：
- 上传大于2MB的图之前，先在本地做一次质量压缩（JPEG质量降到85，肉眼几乎无差别，体积能砍掉一半）
- 优先用图片URL方式传参（如果接口支持），由平台自己去拉图，省掉编码开销和请求体膨胀
- base64字符串注意不要带
data:image/jpeg;base64,前缀，绝大多数接口只认纯base64，带了就报参数错误
3. 一次完整调用的代码骨架与逐段拆解
3.1 请求体的构造：URL传图与base64传图怎么选
这两种方式我得单独说，因为选错了会在生产环境反复出问题。
URL传图的好处是请求体小、传输快，但要求这个URL公网可达。如果你的图片存在内网对象存储里，或者带签名且签名有效期很短，平台拉图就会失败。而且拉图是异步的，超时时间你控制不了，偶发的拉取超时会让整个请求变成"未知状态"。
base64传图的好处是不依赖外网可达性，把图直接塞进请求体，确定性强。缺点是体积膨胀33%，且有长度上限。
我的选择是：内部系统生成的图走base64，用户上传后已经有公网CDN地址的走URL。下面这段是base64方式的完整请求构造：
public byte[] enhanceByBase64(byte[] originImage, String accessToken) throws IOException { String base64 = Base64.getEncoder().encodeToString(originImage); RequestBody form = new FormBody.Builder() .add("image", base64) .add("type", "photo") // 场景类型，常见 photo / scan / text .build(); Request request = new Request.Builder() .url("https://{your-api-host}/rest/2.0/image-process/v1/image_quality_enhance" + "?access_token=" + accessToken) .post(form) .build(); OkHttpClient client = new OkHttpClient.Builder() .connectTimeout(10, TimeUnit.SECONDS) .readTimeout(30, TimeUnit.SECONDS) // 增强耗时较长，读超时要放大 .writeTimeout(30, TimeUnit.SECONDS) .build(); try (Response response = client.newCall(request).execute()) { String body = response.body() == null ? "" : response.body().string(); if (!response.isSuccessful()) { throw new IOException("调用失败 HTTP " + response.code() + " body=" + body); } // 返回体结构大致是 {"image": "base64..."} 或 {"image_url": "..."} String outBase64 = JsonPath.read(body, "$.image"); return Base64.getDecoder().decode(outBase64); } }看到这里你可能会问，type这个参数是必须的吗？不一定，各家设计不同，有的按场景分，有的按强度分，有的干脆没有。但只要有，就一定按场景传对，因为通用场景下的增强策略对文字图往往会过度锐化，笔画边缘会出现毛刺。
3.2 超时参数的取值为啥不能照抄默认值
OkHttp默认的读超时是10秒，这对普通接口够用，对图像增强不够。一张4MB的图上传就要几秒，服务端处理又要几百毫秒到几秒，返回的base64还有4MB要下载，整体很容易超过10秒。
我最初就是因为这个踩了坑：压测时偶发SocketTimeoutException，但接口成功率看板上显示99.2%，看起来还行。直到用户投诉"点了增强转圈很久然后失败"，我才去翻日志，发现超时集中在晚间高峰期的大图请求上。把读超时从10秒调到30秒之后，超时率直接降到万分之一。
注意：超时时间调大不是万能的。如果你的业务是同步接口（用户点了按钮等结果），30秒的等待体验很差，这时候应该改成异步任务——提交任务拿taskId，前端轮询或者回调通知。判断标准很简单：用户能不能接受等30秒。
3.3 返回结果的解析：别只盯成功路径
响应体解析这块，最容易犯的错是只看成功的情况。写代码的时候顺手JsonPath.read(body, "$.image")，上线后发现某类图返回的是错误结构，JsonPath直接抛异常，异常栈把真正的错误信息盖住了，排查半天。
正确的姿势是先判空、再判错、最后取数据：
public EnhanceResult parse(String body) { EnhanceResult result = new EnhanceResult(); JSONObject root = JSON.parseObject(body); // 先看有没有错误码字段，字段名各家不同，常见 error_code / code Integer errorCode = root.getInteger("error_code"); if (errorCode != null && errorCode != 0) { result.setSuccess(false); result.setErrorCode(errorCode); result.setErrorMsg(root.getString("error_msg")); return result; } String image = root.getString("image"); if (image == null || image.isEmpty()) { // 有的接口返回的是URL而不是base64，两种都要兼容 image = root.getString("image_url"); if (image == null) { result.setSuccess(false); result.setErrorMsg("响应中既无image也无image_url"); return result; } result.setImageUrl(image); } else { result.setImageBytes(Base64.getDecoder().decode(image)); } result.setSuccess(true); return result; }为什么要写得这么啰嗦？因为出错的时候你不在现场，日志里能留下的信息就是唯一的线索。我在EnhanceResult里还专门加了原始响应体字段，出错时打全量日志（注意脱敏，base64内容截断到前100字符），这样回查的时候能直接看到平台到底返回了什么。
3.4 结果落地：临时目录、对象存储还是流式返回
增强完的图怎么存，取决于你的下游。三种情况我都做过：
- 同步返回给前端：直接把
byte[]写进HttpServletResponse的输出流，注意设置Content-Type: image/jpeg和合理的Content-Length，不要忘了把输入流转成输出流时用缓冲。 - 落对象存储：拿到
byte[]之后加一个UUID文件名，上传到对象存储，把key存进业务表。注意文件名一定要随机化，别用原始文件名，否则并发上传同名文件会互相覆盖。 - 落本地临时目录：只在离线批处理里用，务必用
try-finally清理，我见过临时目录堆积了几百GB垃圾文件的案例。
// 落对象存储的一个简化写法 String objectKey = "enhanced/" + LocalDate.now() + "/" + UUID.randomUUID() + ".jpg"; storageClient.putObject(bucket, objectKey, new ByteArrayInputStream(result.getImageBytes()), result.getImageBytes().length);上传时记得带上正确的Content-Type，不然浏览器打开链接会变成下载。
4. 参数调优：清晰度增强不是"拉满就好"
4.1 强度参数与过增强的识别
几乎所有增强接口都有某种形式的"强度"概念，可能是显式的数值参数，也可能是通过场景类型隐式决定。我的经验是：默认值通常是一个偏保守的中间值，直接用它反而最稳，除非你有明确的场景区分需求。
过增强长什么样？三个典型特征：边缘出现白边或黑边（锐化过度导致的halo效应）、平坦区域出现奇怪纹理（模型在无纹理区域硬编细节）、噪点被放大成颗粒（本来轻微的压缩噪点被当成细节强化了）。
判断方法很朴素：把原图和增强图并排放在一起，缩小到50%看整体观感。因为最终用户很多时候是在缩略图尺寸下看图，放大100%盯着看反而是种失真。我在项目里做了一个小工具，把原图、增强图、以及两者的差异图拼成一张三联图，方便人工抽检。
| 过增强表现 | 可能原因 | 调整方向 |
|---|---|---|
| 边缘白边明显 | 锐化强度过高 | 降低强度或换"轻度"模式 |
| 平坦区出纹理 | 模型把噪声当细节 | 先做降噪预处理 |
| 颗粒感变重 | 压缩噪点被放大 | 降强度并配合去噪 |
| 肤色发脏 | 色彩通道被过度处理 | 限制在亮度通道处理 |
最后一行值得多说一句：很多增强算法只处理亮度通道（Y），不碰色度通道（U/V），这样做的好处是不会让颜色跑偏。如果你发现增强后颜色变了，先检查是不是用了会整体重编码的方案。
4.2 人脸图和通用图的差异化处理
人脸是最容易被增强搞坏的对象。原因很简单：人眼对人脸极其敏感，稍微有点不自然就会被察觉，所谓的"恐怖谷"效应在图像增强上体现得淋漓尽致——眼睛放大了但瞳孔变形、皮肤磨平了但毛孔纹理突兀、牙齿被锐化成一片白块。
我的处理原则是：
- 人脸占画面比例超过30%的图，不要在增强之后再做美颜或锐化，叠加处理几乎必然翻车
- 小尺寸人脸（比如监控截图）宁可不增强，因为信息量太少，重建出来的五官大概率是错的，看着更假
- 证件照、头像类图片，强度调到最低，只需要把压缩伪影去掉就够了
通用图（风景、商品、文档）的容忍度高很多，可以放心用中等强度。文档类图片（合同扫描、书籍拍照）还要额外注意一点：增强后文字笔画变粗是常见的，如果后续要接OCR，笔画太粗反而会降低识别率。我做过对比测试，同一批扫描件，不增强直接OCR的准确率是94%左右，增强后是92%——视觉上更好看，机器识别反而差了。所以增强和OCR的先后顺序要看你的最终目标，如果是为了让人看，就先增强；如果是为了让机器读，先试OCR，识别不出来的再增强后重试。
4.3 批量处理的并发控制与QPS限制
单张调用跑通之后，业务方一定会上来问"能不能把我这批历史图片全处理一遍"。这时候就进入批量模式，而批量模式第一个要面对的就是QPS限制。
云平台对新接入的应用通常给一个较低的默认QPS（常见个位数），需要提交工单申请提额。不要想当然地以为"我并发100个线程就能跑满"，超限的请求会直接返回限流错误码，重试还会计入限流，越重试越糟。
我的做法是用信号量控制并发度，配合令牌桶控制速率：
// 并发度控制：同时最多N个请求在飞 private final Semaphore concurrency = new Semaphore(5); // 速率控制：每秒最多M个请求 private final RateLimiter rateLimiter = RateLimiter.create(5.0); // Guava public byte[] enhanceWithLimit(byte[] image, String token) throws Exception { rateLimiter.acquire(); // 先拿令牌，控制速率 concurrency.acquire(); // 再拿许可，控制并发 try { return enhanceByBase64(image, token); } catch (IOException e) { // 限流错误码单独识别，走退避重试 throw e; } finally { concurrency.release(); } }为什么并发和速率要分开控制？因为这两件事约束的是不同维度。并发度约束的是"同时占用的连接数和内存"（每个请求持有一份几MB的base64），速率约束的是"平台侧看到你的调用频率"。只控并发不控速率，短时间内的突发请求照样会被限流；只控速率不控并发，遇到慢响应时会堆积大量线程。
批量跑历史数据的时候，我还会加一个断点续跑机制：每处理完100张就把进度和已完成的ID列表写到本地文件，中断后从断点继续。这个简单的设计在跑10万张图的任务时救了我两次——一次是机器重启，一次是token过期导致整批失败，没有断点续跑的话要重头再来。
5. 生产环境踩过的几个真实坑
5.1 图片转完是歪的：EXIF方向信息丢失
这个问题非常隐蔽，我第一次遇到的时候完全没往这个方向想。用户上传的手机拍的图，预览看着是正的，增强后返回的图躺倒了。
原因在于：手机拍的照片通常带EXIF的Orientation标记，告诉显示端"这张图需要旋转90度/180度才是正的"。很多图片处理链路在读取像素数据时会丢掉EXIF信息，于是返回的图就是像素的原始朝向——也就是歪的。
排查过程是这样的：我先拿了一张用户的原图，用ImageIO.read()读出来直接写成新文件，发现已经是歪的，说明问题出在读取环节而不是增强接口。进一步确认，ImageIO读JPEG时不处理EXIF方向。
解决方式有两种：一是用metadata-extractor这类库读出Orientation，然后手动旋转；二是上传前就用支持EXIF的库把方向"烧"进像素里，再上传。我用的是后者，虽然会多一次解码编码，但后续所有链路都不用再操心方向问题。
// 伪代码示意：读取EXIF方向后旋转到正向 Metadata metadata = ImageMetadataReader.readMetadata(file); ExifIFD0Directory exif = metadata.getFirstDirectoryOfType(ExifIFD0Directory.class); int orientation = exif != null ? exif.getInt(ExifIFD0Directory.TAG_ORIENTATION) : 1; BufferedImage fixed = rotateByOrientation(ImageIO.read(file), orientation);提示：这个问题在自助上传场景里出现频率极高（手机拍照占比大），但在测试环境几乎发现不了，因为测试用的图大多是电脑截图，根本没有EXIF方向标记。
5.2 失败重试的触发条件与退避策略
重试是个双刃剑。不重试，偶发的网络抖动会造成无谓的失败；乱重试，会把限流错误放大成雪崩。
我把失败分成三类，分别处理：
| 失败类型 | 典型表现 | 处理方式 |
|---|---|---|
| 网络类 | 连接超时、读超时 | 重试2次，指数退避1s/2s |
| 限流类 | 特定错误码，提示QPS超限 | 重试3次，退避2s/4s/8s |
| 参数类 | 图片过大、格式不支持 | 不重试，直接失败并记录 |
| 鉴权类 | token失效 | 刷新token后重试1次 |
参数类绝对不能重试，因为它重试一万次结果都一样，只会浪费配额和时间。这点我吃过教训：早期代码里没区分错误类型，所有异常都傻乎乎地重试3次，结果一张超大图导致一次请求变成四次，白白消耗了额度。
还有一点：重试前建议做一次快速的头部检查。比如判断返回的HTTP状态码，5xx和429可以重试，4xx基本不用。有些平台把业务错误也放在200状态码里，靠响应体的error_code区分，这时候就必须解析完响应体再决定。
5.3 计费方式与"失败了要不要钱"
这个不能只凭猜测，我建议你上线前把计费文档翻两遍。大多数平台的规则是"成功返回才计费，调用失败不计费"，但"成功"的定义要看清楚——如果是"请求到达且返回了响应"，那么参数错误导致的失败可能也算钱。
更需要注意的是重复调用。假设你的重试逻辑写错了，或者前端用户狂点按钮，一次增强实际调用了5次，那账单就是5倍。我在网关层加了一道幂等控制：以图片内容的MD5加上参数组合作为key，短时间内的相同请求直接返回缓存结果。
String cacheKey = DigestUtils.md5Hex(imageBytes) + ":" + type; byte[] cached = localCache.getIfPresent(cacheKey); if (cached != null) { return cached; // 命中直接返回，不再发起真实调用 } byte[] result = enhanceWithLimit(imageBytes, token); localCache.put(cacheKey, result); // 用一个几小时的过期时间这一招的效果很直接：我们后台有个"重新增强"的按钮，用户经常连点，加了缓存之后这部分重复调用几乎归零。缓存用什么实现都行，Caffeine、Guava Cache甚至一个带过期的ConcurrentHashMap都能顶，关键是给缓存设过期时间，否则内存会被图片撑爆。
6. 把调用封装成一个可复用的服务类
6.1 接口抽象与多供应商可替换设计
最后一层，讲怎么把前面这些东西收拢成一个干净的类。我踩过的最大弯路是：第一版直接把调用逻辑写在了Controller里，后来要换接口版本、要加降级、要加缓存，改得满目疮痍。
正确的做法是先定一个接口：
public interface ImageEnhancer { EnhanceResult enhance(byte[] image, EnhanceOptions options); }EnhanceOptions里放场景类型、强度、是否保留原尺寸这类参数。然后有一个基于云API的实现，和一个本地降级实现——降级实现什么都不做，直接返回原图，只是为了在API不可用时保证业务链路不断。这个降级实现在一次平台发布窗口期救了我们，当时接口连续返回5xx大概二十分钟，因为有降级开关，用户上传流程完全没受影响，只是那二十分钟的图是原图。
public class FallbackEnhancer implements ImageEnhancer { @Override public EnhanceResult enhance(byte[] image, EnhanceOptions options) { EnhanceResult r = new EnhanceResult(); r.setSuccess(true); r.setImageBytes(image); // 原样返回 r.setFallback(true); // 打个标记，方便后续补偿 return r; } }注意setFallback(true)这个标记——有了它，你就能在事后把这段时间的图捞出来重新处理一遍。没有这个标记，你根本不知道哪些图是没增强过的。
6.2 配置项集中管理与灰度开关
配置我统一收拢到一个配置类里，包含：接口地址、密钥、超时时间、并发度、速率、缓存过期时间、降级开关。这些值绝对不要散落在代码各处，调参的时候会疯。
灰度这块我的做法是加一个按比例采样开关：新参数或者新的强度配置，先只对1%的请求生效，对比两批图的观感和下游指标（比如OCR准确率、用户投诉率），没有恶化再逐步放量。比例值放在配置中心，随时可调，改完即时生效，不需要重启。
6.3 监控指标里最该盯的那几个
上线之后能看的东西很多，但真正有用的就那么几个。我盯的是这四个：
- 成功率：按错误码分组看，不要只看总成功率。参数错误率高说明上游传的图有问题，限流错误率高说明并发配置不合理。
- P99耗时：平均值会骗人。我们平均值是1.2秒，看着不错，P99到了8秒，说明有一批大图在拖尾。
- 平均输入体积：这个指标上升往往预示着上游压缩策略变了或者有人开始批量传大图，是成本和耗时的先行指标。
- 缓存命中率：低于预期说明key设计有问题，或者重复请求比想象中多。
这四项我在项目里做成了一个小看板，异常时钉钉告警。最有价值的是第三个——有一次上游把图片压缩质量从70调到了95，平均体积涨了三倍，接口耗时和费用跟着涨，看板上体积曲线一抬头我们就发现了，当天就定位到了改动。
6.4 一点经验
如果你现在正准备接这个能力，我的建议是先把降级路径和缓存这两件事做掉再谈调优。增强接口本质上是一个可选的能力增强，它挂了不应该拖垮主流程。我见过太多项目把外部API当内部方法一样直接调用，一旦对方抖动，整个上传链路跟着躺平。把接口包一层、加个开关、加个缓存，工作量可能就半天，但能省下的救火时间远超这个投入。
另外，别急着一次把所有场景都覆盖。先挑一类图（比如商品主图）跑通全链路，把观测数据攒起来，再往其他场景推。我第一版上线只覆盖了商品图，跑了两周确认稳定，才放开到用户头像和内容配图，中间调整过三次强度参数，每次都有数据支撑，比拍脑袋调参靠谱得多。
