One API 项目中的缓存响应优化：避免缓存异常空响应

在 API 开发中，缓存机制是提升性能的重要手段，但不当的缓存策略可能导致系统缓存无效或异常响应。最近，One API 项目针对缓存响应机制进行了重要优化，解决了当第三方接口返回空响应时仍被缓存的问题。

问题背景

在 One API 的实际使用中，开发者发现一个潜在问题：某些第三方接口在异常情况下不会抛出错误，而是返回空的响应内容。当系统开启缓存功能时，这些空响应会被错误地缓存下来，导致后续请求可能一直获取到无效的空响应数据。

技术分析

One API 原有的缓存机制对所有成功响应（HTTP 200）都会进行缓存，没有对响应内容进行有效性校验。这种设计在大多数情况下工作良好，但当遇到以下情况时就会出现问题：

1. 第三方接口内部错误但返回 HTTP 200 状态码
2. 响应体为空或包含无效数据
3. 流式响应中内容为空但结构正确

解决方案

项目维护者针对这一问题实施了多层次的优化：

1. 非流式响应处理：

   • 对于普通 API 响应，增加内容空值检查
   • 如果响应体为空，则不进行缓存操作

2. 流式响应处理：

   • 当流式响应出现错误时，自动跳过缓存
   • 对于 HTTP 200 的成功流式响应，如果完成标记（tokens）为零，则不缓存

3. 聊天和补全接口专项优化：

   • 这两个高频接口的缓存增加了完成 tokens 数量检查
   • 零 tokens 的响应将被视为无效，不进入缓存

技术实现要点

该优化的核心在于在缓存写入前增加了响应有效性校验层。主要检查点包括：

• 响应体非空检查
• 流式响应错误标记检查
• 完成 tokens 数量检查（针对特定接口）

这种设计既保证了正常响应的缓存效率，又避免了异常响应的错误缓存，提高了系统的可靠性。

对开发者的启示

这一优化案例给 API 开发者提供了几个重要启示：

1. 缓存策略不应仅依赖 HTTP 状态码
2. 对第三方接口的异常处理要考虑各种边界情况
3. 流式响应的缓存需要特殊处理
4. 针对不同接口类型可能需要定制化的缓存策略

One API 的这一改进展示了如何通过细粒度的缓存控制来提升系统的健壮性，值得其他类似项目参考借鉴。