北京
今年七月，我发现自己的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，可能比想象的要多。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
