摘要

  • 1997 年 1 月，RFC 2068 把 402 Payment Required 写进 HTTP/1.1，随后只给出一句规则：“保留供未来使用”。
  • RFC 2616、RFC 7231 和 RFC 9110 都沿用了这项保留。HTTP 至今没有为 402 定义通用价格、付款挑战或结算约定。

有号码，没有收银台

RFC 1945 把状态码解释为机器可读的请求结果，并列出 HTTP/1.0 当时认可的具体代码。在客户端错误列表里，401 Unauthorized 后面就是 403 Forbidden；402 没有列入。文档允许扩展代码，所以未列出的号码仍可作为扩展使用。缺的是 RFC 1945 自己给它的定义。 RFC 1945 §§6.1.1–6.1.2

1997 年 1 月的 HTTP/1.1 规范让 402 正式出现在状态码语法中。RFC 2068 还为它单列第 10.4.3 节，全文只有一句：“This code is reserved for future use.” 名称指向一道收费门槛，规范正文却没有描述门后该发生什么。 RFC 2068 §§6.1.2、10.4.3

一个状态码可以告诉程序服务器返回了哪类结果，却不能凭空完成交易。402 的定义没有写金额、币种、收款方、付款凭证、确认方式、结算或争议处理。服务器可以在响应正文里解释自己的条件，但 HTTP 没有让这些条件在不同客户端和服务之间通用。

401 有挑战字段，402 只有候场号码

相邻的 401 展示了什么叫共享交互规则。RFC 9110 要求 401 响应携带 WWW-Authenticate，其中至少有一个适用于该资源的认证挑战。客户端可以读出机制，再决定怎样提交凭据。第 15.5.3 节没有给 402 配置相应动作，只把“保留供未来使用”又写了一遍。 RFC 9110 §§15.5.2–15.5.3

于是具体工作落在应用层。服务若要把资源放在付款之后，应用必须自己约定应付多少、买方怎样证明已付、钱付给谁，以及证明失败或结算未完成后如何处理。HTTP 提供一个拒绝标签，应用还得搭出收银台、收据和后续流程。

“未来”在每一版规范里续了期

1999 年 6 月的 RFC 2616 在第 10.4.3 节重复了同一句话。RFC 7231 于 2014 年重写 HTTP/1.1 语义，仍把 402 留给未来。2022 年的 RFC 9110 又保留了同样的状态。章节编号变了，付款规则没有出现。 RFC 2616 §10.4.3 · RFC 7231 §6.5.2

这些 RFC 没有说作者当年想采用哪种支付系统。一份写明目标方案的同期设计记录会改变这段历史。目前公开的规范只留下状态名称和保留决定，没有给它补上来历。

本文查阅的 IANA 登记页最后更新于 2025 年 9 月 15 日，仍将 402 列为 “Payment Required”，并指向 RFC 9110 第 15.5.3 节。IANA HTTP 状态码登记簿

接口的成本回到了开发者手里

这正是开发接口的经济账。共享协议可以让每支开发团队少写一套私有交易说明；HTTP 的 402 没有替它们省下这一步。买方客户端和服务器还得在应用层约定价格、凭证、身份校验、重试和支付完成条件。集成与维护工作由开发团队承担，各服务则继续控制自己的收费条款。

所以，402 是一种状态名称，不是支付接口。它能表明服务器把访问和付款联系起来，却没有给客户端通用的履约方法。在 HTTP 里，收银台仍是每个应用自己的规则，只是挂上了一个标准号码。

来源