题干与适用场景
这道 HTTP 与 API 基础题适合后端、平台、SRE 和基础设施岗位。请求在原则上有效，但服务器因为配额、文件系统、内存预算或应用限制耗尽，无法保存最终资源状态。回答要说明 507 何时有意义、何时应选其他状态码，以及如何避免重复写入。
面试官考察点
- 能否区分服务端容量耗尽与请求无论如何都过大的情况。
- 是否知道 507 源自 WebDAV，表示临时的服务端条件，不是通用校验错误。
- 能否定义重试、退避、幂等和用户补救动作，同时不隐藏原因。
- 能否沿着应用、存储、配额、代理和缓存层定位真正的限制。
回答前需要澄清的问题
先问失败的操作、请求表示是否合法、耗尽的是哪种资源、限制是否按租户划分，以及操作是否已经留下部分状态。确认客户端能否安全重试、服务是否提供配额或容量信号。若内容无论当前容量如何都超过策略或解析器限制，应使用 413；若服务整体暂时无法处理请求，503 可能更准确。不要因为某台机器出现磁盘告警，就把所有写入失败都归为 507。
30 秒回答框架
当操作本身有效，但服务器因为可用存储或适用的服务端限制耗尽而无法记录最终资源状态时，我会返回 507。413 表示请求过大，503 表示更广泛的暂时不可用，三者边界要按实际故障层判断。响应包含稳定的错误类型和请求 ID，不泄露内部路径。只有幂等操作或带幂等键的写入才允许带界限退避重试；运维需要找出耗尽的具体维度、释放或扩容，并在恢复后验证完整写入。
分步骤深入解答
- 先分类故障。 RFC 4918 将 507 定义为方法执行后无法记录资源状态，因为目标端没有足够空间。MDN 也说明实现中可能用于其他耗尽的服务端资源或应用限制。关键条件是请求有效，却被服务端容量边界阻断。
- 区分相邻状态码。 内容独立于当前容量都过大时返回 413；状态冲突或前置条件失败时使用 409 或 412；服务整体处理能力暂时不可用时使用 503，并可配合
Retry-After。507 不应成为所有写入失败的兜底。 - 让错误可行动。 返回稳定的 problem type、可读标题、请求 ID；只有预期容量会恢复时才给重试提示。租户配额可以给安全的配额标识或补救入口，但文件路径、主机名和内部策略留在日志中。
- 保护重试。 上传超时后提交状态可能未知。要求幂等键或可恢复上传令牌，保存操作状态，让客户端先查询再重放。设置指数退避和总期限；无限重试会进一步放大资源耗尽。
- 定位资源边界。 记录可用字节或 inode、对象存储配额、数据库或 blob 暂存、内存限制、租户分配以及发出 507 的层。通过请求 ID 对齐应用日志和存储指标，避免把代理错误误认为源站决定。
- 恢复并验证。 必要时暂停或拒绝新写入，释放或扩容后用原幂等键重试有界操作。核对对象校验和、元数据、可见性与配额账本。为重复故障设告警，并验证一个租户耗尽资源时不会侵占另一个租户的预留量。
高质量示范回答
我只在请求有效、但服务器因为存储或其他服务端资源限制无法保存最终状态时使用 507。固定请求大小策略导致的失败用 413；维护或整体过载导致的暂时不可用可能用 503。响应提供稳定的错误类型和请求 ID，只有容量确实可能恢复时才提供重试提示：
HTTP/1.1 507 Insufficient Storage
Content-Type: application/problem+json
Cache-Control: no-store
Retry-After: 120
{
"type": "https://api.example.com/problems/storage-exhausted",
"title": "The resource could not be stored",
"status": 507,
"detail": "The workspace storage limit prevented this operation.",
"request_id": "req-7f2"
}客户端不能盲目重发状态未知的上传，而应使用同一个幂等键或先查询操作状态。运维把请求与配额、暂存区、对象存储、数据库和 inode 指标关联，恢复后核对校验和、可见性与账本。若网关返回 507 而源站返回 200，就把网关视为发出错误的层，并逐跳验证。
常见错误
- 把请求过大返回 507 → 容量变化也不会让它合法 → 固定大小策略应使用 413。
- 每次 507 都立即重试 → 已满的资源会更拥塞 → 使用有界退避和操作期限。
- 超时后重放上传 → 原写入可能已经成功 → 查询状态或复用幂等键。
- 只说“磁盘满了”却不定位边界 → 配额、inode、暂存区和对象存储可能分别失败 → 识别发出层和耗尽维度。
- 向客户端返回路径和主机名 → 可能泄露拓扑和租户信息 → 返回稳定错误类型与请求 ID，诊断留在受保护日志中。
追问及应对
客户端应重试 HTTP 507 吗？
只有操作可安全重试且容量预计会恢复时才重试。写入要使用幂等键或状态查询，配合指数退避和总期限。若是硬性租户配额，应提供补救动作而不是继续重试。
如何区分 507 与 503？
507 指向保存有效资源状态时遇到存储或服务端限制；503 指向更广泛的暂时无法服务，可能来自维护或过载。依据测量到的故障边界和一致的服务策略选择，不要只凭 HTTP 层猜测。
源站成功但代理返回 507 怎么办？
用请求 ID 对比直连源站、代理和冷缓存请求。代理就是发出错误的层，可能拥有自己的缓冲区或配额。重试前先核对客户端最终状态，因为源站可能已经保存资源。