在 okhttp 拦截器中，绝不可手动调用 response.body().close()，否则将导致后续调用方无法读取响应体，引发 ioexception 或空响应等隐蔽错误。
在 okhttp 拦截器中，绝不可手动调用 response.body().close()，否则将导致后续调用方无法读取响应体，引发 ioexception 或空响应等隐蔽错误。
OkHttp 的责任链模型要求拦截器仅负责转换、重试或增强请求/响应，而不承担资源释放职责。Response 对象的生命周期由最终消费方（如 Retrofit 的 CallAdapter、手动调用 response.body().string() 或 response.body().bytes() 的业务代码）管理。一旦你在拦截器中提前关闭 response.body()，后续代码再尝试读取时会抛出 IOException: closed，且该异常往往难以定位。
以你提供的限流重试拦截器为例：
public Response intercept(Chain chain) throws IOException {
Response response = chain.proceed(chain.request());
if (!response.isSuccessful() && response.code() == 429) {
LOG.error("Rate limit exceeded. Waiting 20 seconds.");
try {
Thread.sleep(20_000);
} catch (InterruptedException e) {
Thread.currentThread().interrupt(); // ✅ 正确处理中断
throw new IOException("Interrupted during rate-limit wait", e);
}
// ✅ 安全：重新发起请求，旧 response 将被 GC（前提是未被持有）
response = chain.proceed(chain.request());
}
return response; // ❌ 不要在此处 close()
}
⚠️ 关键注意事项：
- 禁止在拦截器中调用 response.body().close() —— 这是核心原则；
- 若需读取响应体用于日志或判断逻辑（如检查 JSON 错误码），必须使用 response.peekBody()（非消耗性）或确保 response.body().source() 被完整消费后交由下游处理；
- 重试逻辑中，原 response 在被新 response 覆盖后，若无强引用，将由 JVM 自动回收；其 body 的底层连接资源（如 socket）由 OkHttp 连接池统一管理，无需也不可手动干预；
- 真正需要关闭响应体的场景，只发生在业务层最终消费之后，例如：
try (Response response = client.newCall(request).execute()) { String body = response.body().string(); // string() 内部已关闭 source // ✅ 安全：无需再 close() } // 或显式 close()：response.body().close() —— 仅在此类明确作用域末尾
✅ 总结：OkHttp 拦截器是“中间件”，不是“终结者”。它应保持响应可传递性，把资源清理权完整交还给调用栈顶层。遵循这一原则，既能避免 closed 异常，也能保障连接复用、响应缓存等核心机制正常工作。
