把 HTTP 里那条“要付款”的状态码真正用起来：L402 的认证与支付合一

被闲置的状态码与拼出来的协议

HTTP 规范很早就在 4xx 家族里留了一个空位：402 Payment Required。RFC 9110 在描述它时的口径依然是“保留供未来使用”——近三十年里浏览器、框架、网关都不认识它，服务器就算返回 402，客户端也只当未知错误。L402 做的事情是把三条现成的零件拼进这个空位：闪电网络的 BOLT 11 发票负责收钱，macaroon 负责授权，402 与 WWW-Authenticate 头负责触发。它的名字就是从“L（Lightning）+ 402”而来，参考实现是 Lightning Labs 的 Aperture——一个懂这套握手的反向代理。

一条链上的支付凭证为什么能被拿去当登录票用，是这套协议最反直觉的一点，也是理解后面所有机制的钥匙。

把 HTTP 里那条“要付款”的状态码真正用起来：L402 的认证与支付合一图 2 — 把 HTTP 里那条“要付款”的状态码真正用起来：L402 的认证与支付合一 · 图 2

握手四轮：从被拒到放行

流程值得逐步走一遍。第一轮，客户端普通请求某个付费资源，服务器判断他没付过钱，返回 402，同时在 WWW-Authenticate 头里带上两样东西：一段 base64 的 macaroon 和一个 BOLT 11 发票。第二轮，客户端用钱包把发票付掉，闪电网络付款的副产品是支付原像（preimage）——发票里那个支付哈希的SHA-256 原像。第三轮，客户端重发请求，Authorization 头里同时带上 macaroon 和原像。第四轮，服务器验证后放行，返回 200。

关键的验证发生在一台不需要数据库的服务器上：macaroon 的标识符字段在签发时就承诺了这张发票的支付哈希，服务器收到凭证后只需做一次哈希比对——支付哈希是否等于原像的 SHA-256——再加上验一遍 macaroon 自己的签名。两样都是无状态的纯计算，服务器不需要记得“我给谁开过哪张票”。凭证被标记为“一次一用”（one-time-use）时，重复出示同一原像会被拒绝；凭证无效或被篡改则回到 401。

macaroon：一张可以越用越窄的饼干

macaroon 是 Google 提出的Bearer 令牌格式，L402 直接拿来做授权载体。对内容运营来说，它的真正价值在于 caveats（限制条款）机制：持有者可以对令牌做“衰减”，给一张六个月内不限次的通行证盖上一层层追加的限制——限定到某个具体接口、限定总额、限定到期时间——加完之后它依然是合法凭证，只是权限变小了。这种“只会变窄、不会变宽”的性质让第三方（比如代付服务、内容分发方）可以安全地持有一张已经收紧过的票。这条性质也是当下 AI 代理场景看重 L402 的原因：代理被委派干活时，拿到的应当是收窄过的凭证而不是原始凭证，泄露的爆炸半径被结构压住了。

一次一用怎么在免查库的前提下成立

无状态验证听起来像不可能三角：既不存库、又要防重放。机制的答案把成本挪到了支付层——同一张发票的原像是唯一的，把它公开出示就等于宣告“这张票我用了”。服务器不需要全局记账，只需要在这张发票的生命周期内拒绝第二次见到同一个原像；实现通常用短过期的挑战或本地小缓存兜住这个窗口。换句话说，L402 的防重放建立在闪电自身的支付哈希结构上，而不是另建一套会话系统。这带来的运维含义是明确的：这类凭证的时效性取决于实现方的存储策略，把它长期当 API Key 收藏是不合适的用法。

和 x402 的分野

两件事容易混。一件是 x402——由 Coinbase 一方推动、面向稳定币结算的机器支付方案，用稳定币转账加签名回执换取访问，仓库自述里明确说明它借鉴了 L402 借用 402 状态码的思路；另一件是 IETF 里以“Payment”为名注册认证方案的标准化草案，尝试做支付方式无关的 402 语义。L402 本身不是 IETF 标准，而是围绕闪电网络成文的事实协议，这一点在两者的定位上分野清晰。选型时看底层结算网络即可：要闪电结算、要 macaroon 式细粒度权限，对应 L402 的机制组合；要稳定币结算，那是另一套签名与回执语义。