1. 现象与误判
某代购集运系统监控中 499 与 504 曲线同步抬升。值班人员分头排查客户端与下游，两小时后确认两侧均无异常——两条曲线来自同一条链路。此外，故障的真实损失（一批在客户端放弃后仍被执行完成的订单写入）未反映在任何告警中。
2. 语义界定
| 状态码 | 报告方 | 准确含义 | 常见误解 |
| 499 | 反向代理 | 客户端在响应返回前主动关闭连接 | 请求未被执行 |
| 504 | 网关 | 约定时间内未等到上游响应 | 下游系统故障 |
关键认知：两者均不表示「事情没发生」。499 场景下服务端大概率已执行完成；504 场景下下游多数仍在正常运行。
3. 成因：预算倒挂
| 环节 | 超时 | 行为 |
| 客户端 | 3 秒 | 主动断开 |
| 网关 | 5 秒 | 返回 504 |
| 应用 | 10 秒 | 网关放弃后继续执行 |
| 下游 | 30 秒 | 应用放弃后继续执行 |
倒挂产生三笔账：幽灵写入（外层放弃后里层写库成功，用户重复下单，形成疑似人工重复的重复单）；资源无效占用（僵尸请求占用线程、连接与调用配额，高峰期可达连接池三成，并进一步推高 504）；监控错位（499 常不计入 5xx 告警，故障在 504 抬升前处于静默状态）。
4. 修正方案
预算从外向内倒推分配，剩余时间逐跳透传：
TOTAL_BUDGET_MS = 3000 def handle(request): deadline = request.now_ms() + TOTAL_BUDGET_MS return call_downstream(deadline=deadline) def remaining_ms(deadline): return max(0, deadline - now_ms()) def call_downstream(deadline): left = remaining_ms(deadline) if left < 200: raise BudgetExhausted("no time left for downstream call") return http_post( "/purchase/create", headers={"X-Deadline-Ms": str(left - 100)}, timeout=(left - 100) / 1000, )
写库前执行预算检查：
def after_upstream_ok(intent, result, deadline): if remaining_ms(deadline) <= 0: save(intent, result, flag="CLIENT_GONE") enqueue_reconcile(intent) return save(intent, result)
配套原则：每跳保留 10% 收尾余量；499 不进入重试，仅标记与统计；超时值按 P99 而非平均值确定；为「客户端已断开但服务端仍在执行」建立独立监控指标。
5. 验收清单
- 全链路超时值汇总于同一张表，里层一律小于外层
- 剩余预算逐跳透传，不各配默认值
- 每跳保留 10% 收尾余量
- 写库前检查预算，超时写入打标记进对账队列
- 499 不重试
- 超时按 P99 确定
- 告警覆盖 499
- 每月核对超时预算表与实际代码的一致性
6. 结语
499 与 504 是同一条链路上「谁先放弃」的两种记录。预算不倒挂，两个状态码自然消失；倒挂状态下，单独调大任一环节的超时均无效。建议将「全链路超时预算表」纳入常规配置评审范围。
