LNURL是什么？一张静态二维码如何长期收闪电付款

问题的起点：闪电发票太重、太短命

闪电网络最经典的收款凭证是BOLT11发票：一串lnbc开头的长字符串，里面锁定了金额、描述和有效期。它的致命短板是”一次一张”——每笔收款都要新生成、新展示、新扫码，商家要么架一台能实时出码的设备，要么让顾客隔几分钟就来问一次”新的码好了吗”。更常见的妥协是干脆贴一张不带金额的收款地址，可闪电网络里根本不存在这样的静态地址。LNURL解决的正是这个空位：给商家一串永久有效的凭证，把”生成发票”这件事延后到付款瞬间，由商家的服务器替你完成。

拆开那串lnurl1开头的字符

钱包扫出的LNURL形如lnurl1加一长串小写字母数字。别看它像地址，其实它只是一次bech32编码——把一段普通的HTTPS网址按闪电网络地址同款编码法包起来。解码后往往就是类似https://service.example/?q=3fc3645b439ce8e7的查询链接。bech32自带校验位，抄错、截断一个字符都会被当场识破，这是它取代裸网址显示的原因之一。理解这一点很重要：所谓LNURL，本质是一个被包装过的服务端入口，收款逻辑全部发生在那台服务器上。

三步走通的payRequest流程

LNURL付款（规范文档中的LUD-06 payRequest）实际是三个HTTP回合。第一步，钱包用GET请求访问解码出的网址，服务器返回一份JSON：标签payRequest，外加callback回调地址、minSendable与maxSendable两个以毫聪计的金额边界，以及一段元数据（纯文本描述、图片等）。第二步，钱包展示商家名称、金额区间，让用户输入金额，再GET回调地址并带上amount参数。第三步，服务器此刻才现做一张BOLT11发票返回，钱包核对发票的描述哈希是否等于元数据的SHA-256、金额是否落在区间内，然后支付。整个过程里那张静态码纹丝不动，变的只是服务器嘴里的发票。

用之前先核对的四件事

LNURL把信任锚从密码学挪到了域名上，核对清单因此变得具体。一核域名：付款界面必须显示LNURL解出的真实域名，钓鱼者换的正是那台域名的服务器。二核金额边界与元数据：区间异常宽、描述文不对题的码要警觉。三核发票一致性：描述哈希对不上时钱包应拒付，别用忽略警告的旧版本。四认清隐私边界：LNURL收款时服务方知道你要付多少钱才拿到发票，这与直接扫一张含金额的发票不同；若你更在意这种交互泄露，可以选择直接出示一次性BOLT11发票的收款方。它不涉及任何链上写操作，费用也只在闪电路由层面发生，理解流程之后再扫那些贴在摊位上的”万能码”，心里就有底了。

顺带认全LNURL家族的其他成员

同一套编码与HTTP骨架还撑着几个变体，见到时不至于陌生。withdraw是反向版：服务方先给一张带金额区间与会话标识k1的取款凭证，你的钱包生成发票让它来付，常见于水龙头与返现平台——注意付款方向反过来时，你的隐私暴露面也变了，服务方看到的是你的节点身份而非对方的。auth是免密码登录：网站丢来一个挑战值，钱包用按域名派生的密钥签名回应，全程不传口令，理论上比短信验证码更抗钓鱼，但依赖钱包厂商的密钥派生实现。channel是闪电流动性申请：钱包请服务方给你开一条有余额进账能力的通道。这些能力共用bech32外壳与域名信任模型，因此前文那四条核对纪律同样适用。还有一条工程伦理层面的提醒：LNURL让收款方服务器知道你在什么时间、准备付多少钱，服务方的日志策略决定了这段信息的存续，选择服务商时这也是可以问一句的事。