今年七月，我发现自己的 x402 支付网关服务出了个魔幻现象：链上 USDC 照常到账，可新请求量悄悄掉了一大截。查日志时翻到一行 invalid_payload，盯了三个星期，一直当背景噪音。直到把服务注册到 x402scan，才被系统冷冷地怼回来—— " 检测到 x402 v1 响应，请迁移到 v2 规范 "，外加一条缺失发现文档的抱怨。原来不是没流量，是流量根本找不到你的门。

这事儿的本质很直白：如果你在 2026 年中之前上线的 x402 服务，那就是 V1 版。它不会崩溃，付款也继续结算。但两个静默的变化已经在抽走你的请求。第一个是 x402scan 充当了自主代理的 " 黄页 "，V1 来源提交上去直接遭拒，等于在发现层就被隐身。第二个更隐蔽：那些已经开始用 V2 协议的客户端，尝试对你的 V1 中间件发起支付时，立刻被 invalid_payload 击退，然后悄无声息地失败。你日志里所有无法解释的 invalid_payload，很可能就是真金白银的请求在撞墙。

下面这五个变化才是真正吃时间的硬骨头。

一、包名搬家。别再用 x402-hono 了，它永远停在 1.2.0。新的活线在 @x402/* 域下，框架适配包像 @x402/hono、核心包 @x402/core、EVM 链包 @x402/evm，还有扩展包 @x402/extensions。配合 Coinbase 的 CDP facilitator，出了个 @coinbase/x402。截至核验，@x402/* 在 2.19.0，@coinbase/x402 在 2.1.0。这行迭代快，装之前务必确认最新版。

二、挑战从 body 直升 header。V1 的 402 响应在 JSON 肚子里塞挑战信息，而 V2 把 body 清空，只返回一个 payment-required 头，挑战值直接 base64 编码进去。这个调整直接炸了所有依赖旧 body 解析的客户端，也是 invalid_payload 的主要源头。

三、网络标识改用 CAIP-2 格式。以前写 8453 或者字符串，现在必须给成 eip155:8453。这个改动倒不大，但忘了的话，签名验证直接挂。

四、CDP facilitator 原生支持身份认证。如果你曾经为了签发 JWT 去刨 SDK 内部逻辑，现在可以把手伸回来。V2 已经内置了这块，省掉一大段自己维护的胶水代码。

五、X-Forwarded-Proto 被无视。假如你在隧道或反向代理后面做的 TLS 终结，资源 URL 会老老实实显示成 http://，除非你手动设置协议头。之前 V1 自动信任 X-Forwarded-Proto 的日子结束了。

安装这一步也有个阴沟。在命令行敲 npm install @x402/hono@2 @x402/core@2 @x402/evm@2 @coinbase/x402@2 --legacy-peer-deps 几乎甩不开 --legacy-peer-deps。原因是 @x402 的一个可选付费墙依赖跟 React 19 绑上了，如果你的项目还停留在 React 18，或者依赖树里存在任何其他 React 版本，npm 会直接拒绝整个安装。付费墙本身就是个可选组件，跟核心支付逻辑压根不沾边，却被这个 peer 依赖卡脖子。

迁移不只是换几个包。当 x402scan 替你挡掉所有流量，当自主代理连你的服务都发现不了，V1 的 " 安静运行 " 就成了最有欺骗性的停摆。翻一下老日志，看看那些读不懂的 invalid_payload，可能比想象的要多。