后端面试：如何设计 HTTP 413 Content Too Large 的处理契约？

题干与适用场景

一个视频上传请求可能经过 CDN、API 网关、应用服务和对象存储，每一层的可接受大小不同。请设计 413 Content Too Large 的响应、限额发现、分片或会话恢复、Retry-After、错误体和监控方案。

这是后端 API 可靠性题。视频大小和层数是题设，不代表市场频率。

面试官考察点

• 能否区分永久超限、临时容量问题和正文校验失败。
• 能否正确解释 413 与 Retry-After 的关系。
• 能否设计可恢复上传而非盲目重试完整正文。
• 能否处理多层代理限额、幂等和错误信息泄露。

回答前需要澄清的问题

1. 413 来自哪一层，响应是否保留了限制范围和请求 ID？
2. 限制按单请求、租户、对象、时间窗口还是剩余配额计算？
3. 客户端是否支持分片、断点续传和查询上传会话？
4. 超限是固定配置还是因容量、配额而暂时发生？
5. 已接收部分是否会产生计费、锁或对象元数据副作用？

30 秒回答框架

“413 表示服务器拒绝处理过大的请求；固定大小限制不应让客户端盲目等待，临时条件才适合提供 Retry-After。边缘层应尽早拒绝并返回稳定错误码、请求 ID 和可公开的上限，应用层仍校验真实字节数。大文件走创建上传会话、分片和幂等完成提交，断线先查询状态。客户端只按 Retry-After 或会话状态恢复，不重复发送已确认分片。我会按每层、租户和大小分布监控 413。”

分步骤深入解答

1. 先分层限制

固定上限、租户配额、对象策略和运行时容量应有清晰来源。边缘网关可用 Content-Length 先拒绝，应用还要检查实际接收字节、压缩展开后的大小和内容策略。错误响应应带请求 ID；不暴露内部节点、真实磁盘容量或其他租户信息。

2. 正确理解 Retry-After

RFC 9110 允许服务器在 413 条件暂时存在时生成 Retry-After，其值可以是 HTTP 日期或延迟秒数。固定限制通常不能靠等待解决，客户端应修改请求或使用分片；有明确恢复时间的配额或维护窗口才适合重试。客户端要限制最大等待并处理无效或过大的值。

HTTP/1.1 413 Content Too Large
Retry-After: 120
Content-Type: application/problem+json
X-Request-Id: req-81a

3. 让错误体可行动

错误体可包含稳定错误码、作用范围、允许的上传模式、最大单片大小和上传会话入口。不要把网关实现名、堆栈或数据库错误直接返回。客户端根据错误码选择压缩、缩小、分片或重新申请配额，而不是对相同正文无限重试。

4. 使用可恢复上传

大对象先创建上传会话，服务端返回会话 ID、过期时间、分片大小范围和已完成分片查询接口。每片使用内容摘要和幂等键；完成操作只引用已验证分片。收到 413 时，客户端可以缩小新分片或重新创建会话，不必重传已确认数据。

5. 处理多层不一致

网关可能先于应用返回 413，应用也可能因解压、配额或策略拒绝。统一错误模型不能假设每层都能知道最终上限；服务端可在创建会话时返回当前可用约束，监控不同来源的 413，并避免把一个层的临时值缓存成全局永久值。

6. 绑定重试、计费和监控

客户端收到 413 后先分类：固定限制改请求，临时限制遵循 Retry-After，会话失败查询状态。服务端用幂等键防止完成提交重复扣费，定期清理过期会话。监控来源层、租户、请求大小、已上传字节、Retry-After 遵从率、分片重传和最终成功率，检测限制配置漂移。

高质量示范回答

“我先确定 413 的产生层和限制类型。固定上限直接返回 413 与可公开的上限或分片入口；只有临时配额或容量条件才返回 Retry-After。大文件通过上传会话和分片完成，分片带摘要和幂等键，客户端断线先查询已确认片。边缘层尽早拒绝，应用层仍校验真实字节和解压后大小。错误体只给稳定码、请求 ID 和下一步。我要监控 413 来源、大小分布、等待遵从、重复提交和最终恢复率。”

常见错误

• 所有 413 都返回 Retry-After → 固定限制会造成无效等待 → 只对暂时条件提供时间。
• 把上限写死在客户端 → 多层配置漂移 → 会话返回当前约束并监控来源层。
• 重新上传完整正文 → 浪费带宽并增加重复副作用 → 使用分片、查询和幂等完成。
• 只检查 Content-Length → 解压或实际字节可能超限 → 接收过程和内容阶段再次校验。
• 暴露内部限额细节 → 泄露拓扑和容量信息 → 返回稳定错误码和请求 ID。

追问及应对

413 没有 Retry-After，客户端应该怎么做？

不要猜等待时间。把它视为固定或未知限制，读取错误码和会话状态，改用更小请求、分片或人工配额流程；只有服务端明确提供可恢复时间才自动等待。

分片大小也超过某层上限怎么办？

创建会话时返回当前允许范围，并让客户端选择不超过最小有效上限的分片。若中途策略变化，保留已确认片，使用新会话参数继续，避免把旧片重新提交。

网关返回 413，但应用没有看到请求，如何定位？

比较边缘、网关和应用的请求 ID、接收字节和响应来源。若应用完全无记录，优先检查网关上限、路由和请求体转发；不要把缺少应用日志解释成应用拒绝。