动漫壁纸与随机图片 API：先分清“随机”发生在哪一层，再谈缓存与优化

要做一个动漫壁纸或随机图片展示功能，请求本身通常只有一行代码；真正决定体验和成本的，是“随机”和“缓存”这两个目标相互冲突。本文讨论的是接入层面的通用工程判断，不是对 API.PLUS 具体接口的说明：本次没有可用的接口文档正文，因此路径、参数名、限流额度、计费方式和当前可用性均待核实，下面的示例一律使用占位主机名。

一、先确认“随机”发生在哪一层#

“随机图片”至少有三种实现，缓存行为完全不同。接入前应向服务方确认属于哪一种；下表是三种方式的推断性对比，不是对任何具体服务的描述。

实践中第三种最容易同时满足“看起来随机”和“省流量”：图片本身按不可变 URL 长期缓存，随机性只发生在索引层。但前提是接口能返回带 id 的候选集合，这一点待核实。

二、契约里值得先写死的字段#

建议把接口响应当作契约看待，而不是当作一张图片。以下字段属于建议，不是任何服务的既有约定：

• 图片标识（id 或稳定哈希），用于去重与日志关联；
• 图片直链与宽高、格式，便于前端预留占位避免布局跳动；
• 来源与授权信息，壁纸类内容涉及版权，展示页通常需要标注；
• 失败时的错误码与错误信息，且与成功载荷分开。

三、错误与二进制不要混在同一个响应里#

随机图片接口常见两种返回：直接输出图片字节，或返回一段 JSON。若在同一个端点上混用，客户端只能靠 Content-Type 猜。建议在接入层显式判断，示例如下（未执行的示例，仅示意思路）：

// 未执行的示例：主机名、路径与字段名均为占位，不代表真实端点
const res = await fetch('https://api.example.com/v1/random?tag=anime');
const type = res.headers.get('content-type') || '';
if (!res.ok || !type.startsWith('image/')) {
  const detail = await res.json().catch(() => ({}));
  throw new Error(detail.message || `unexpected response: ${res.status}`);
}
const blob = await res.blob();

这段代码没有实际运行，预期行为也不应被当作测试结果。真实验收时需要确认错误响应是否也带 image/*，那是接入层最容易漏掉的分支。

四、去重：把“随机”从概率问题变成体验问题#

服务端的随机并不意味着用户看不到重复。常见做法是客户端保留最近若干条 id，命中则重取，并设置最大重试次数，避免接口异常时陷入循环。若接口本身支持排除参数，可以直接交给服务端处理，但该参数是否存在于 API.PLUS，本次材料无法确认，待核实。

另一个细节是预加载：轮播或全屏壁纸场景下，提前取下一张的字节，能让切换接近无感；代价是流量上升，需要按端侧网络情况决定是否开启。

五、优化顺序：先测回源，再调参数#

合理的顺序是先确认缓存命中情况，再决定是否加随机参数。给请求加变化参数能立刻“解决”重复问题，但也会让所有中间缓存失效，把成本转移回源站。在缺少真实监控数据前，任何关于命中率提升幅度的说法都不可靠。

边界说明：本文不含对 API.PLUS 端点的调用记录、性能数字或价格信息；涉及接口能力、配额与授权条款的部分，请以官方文档为准，并自行完成一次可复现的验收记录。