bitcoin 链接是什么？比特币 URI 语法与 req 参数规则解读

扫码之外：比特币链接的正式语法

网页上点一个 bitcoin: 开头的链接就能唤起钱包填好收款信息，这套写法的现行规范是 BIP321，它取代了更早的 BIP21。它定义了地址之外还能携带什么、哪些参数可以忽略、哪些不能。理解它，才能看懂收款页、进阶支付参数与支付证明扩展在链下是怎么传递的。

语法结构

一个比特币 URI 由方案、地址与可选查询参数组成：bitcoin: 后接地址，可以是旧式 base58 地址，也可以是 bech32 或 bech32m 地址；问号后跟键值参数，用与号分隔。常用参数包括 amount（以比特币为单位的金额）、label、message 等。非 ASCII 文本必须先按 UTF-8 编码，再逐字节百分号编码。方案名与参数键不区分大小写，地址与部分字段可能区分大小写，所以整条链接不能靠肉眼大小写记忆来核对。

能忽略的与不能忽略的

关键设计是 req- 前缀：以 req- 开头的参数属于必选要求，钱包若未实现对该参数的处理，必须把整个 URI 视为无效，而不是装作没看见；没有 req- 前缀的未知参数则可以安全忽略。这条规则划定了链下协商的严肃边界——收款方要求某种支付协议时，用 req- 前缀声明，不支持的钱包就不会静默地用错误方式付款。同名参数方面也有明确规矩：label、message 之类的字段不允许重复出现，而未知键应当允许重复，为将来扩展留余地。

钱包必须等人点头

规范还有一条容易忽略的总则：客户端不得在未获得用户授权的情况下对 URI 采取行动，应当让用户逐笔手动确认支付。换句话说，点击链接本身不应该直接花钱——网页脚本注入、剪贴板替换或恶意弹窗想利用的正是这条边界，用户侧对应的防御是：无论入口多方便，都要在自己的钱包界面里核对完整地址与金额后再确认。

常见误区

把 amount 当成链上承诺：它只是给钱包的预填建议，最终以钱包构造的交易为准。把 label 或 message 当成收款指令：它们是给人看的备注。手工改动带 req- 参数的链接后重放：修改后的链接可能已不被收款方接受。此外要清楚，钱包地址类型支持是另一码事——能识别某类地址与能安全支付给某类地址是两回事。

部署与使用建议

收款方按 BIP321 语法生成并实测链接，避免自造参数造成钱包解析分歧；测试时覆盖大小写、百分号编码与含特殊字符的备注。付款方遇到异常长、含可疑 req- 参数或反复要求切换处理程序的链接，用能完整解析参数的钱包复核再决定。规范原文以 bitcoin/bips 仓库 BIP321 当前文本为准。本文只做机制科普，不构成投资建议。

二维码与桌面集成的细节

图形客户端通常会把自身注册为 bitcoin: 协议的默认处理器，若系统里已有别的处理器，规范允许首次运行时询问用户是否更换。这个集成点正是钓鱼常用的入口：恶意软件悄悄改注册表，点击链接就唤起错误的应用。配套的自查动作是：在操作系统设置里确认当前协议处理程序是你信任的钱包；系统层与钱包层的安全提示叠加，才构成对未授权支付的完整防线。二维码同理——扫码只是把同一条 URI 喂给钱包，信任判定仍发生在钱包的确认界面。把核对地址的责任交给手机屏幕上的完整字符串或带名称的收款方标识，永远好过依赖聊天窗口里被截断的片段。

与其他链上外呼机制的边界

比特币 URI 只负责把意图交给钱包，不承诺交易形态、不协商协议、也不证明收款方身份；这些职责分别由其他协议承担。例如进阶的收款协商会在 URI 里附加端点参数，把协商搬到链下 HTTP 通道，那已超出 URI 规范本身的范围。把每一层职责分清，排查问题才不会找错地方：地址报错查编码与钱包版本，参数不被识别查 req- 规则，付款结构异常查具体协议实现。