地址与 URI 分别表达什么
数字钱包的地址与 URI 可以包含相同的收款目标，但承载的信息层次不同。地址用于标明收款目标；支付 URI 可以在地址之外表达金额及说明，使支持相应规则的软件理解一项支付请求。
RFC 3986 定义的是 URI 的通用语法，具体含义由各 URI 方案规定。Bitcoin 开发者指南中的 BIP21 则展示了地址与支付参数如何组合。下文涉及金额和标签的细节适用于这一示例，不能直接推广到所有数字钱包。
误区一：URI 就是加了前缀的地址
只有地址时，两者看起来可能仅差一个方案前缀。但 URI 一旦带有参数，就表达了更多请求信息。同一地址可以出现在不同请求中，因此地址相同，不代表整个 URI 的含义相同。
反过来，只提取 URI 中的地址，也不能视为完整保留了原请求：金额或说明可能随之丢失。识别收款目标与理解请求内容，是两个不同层面的工作。
误区二：二维码一定只是地址
二维码是一种数据承载形式，里面可以是地址，也可以是包含参数的 URI。外观看起来相似的二维码，解码后的内容结构可能不同。
因此，二维码的形状不能说明它包含哪些字段。成功识别图像，也只表示取得了其中的数据，并不证明软件已经正确理解所有支付参数。
误区三：金额单位跟随钱包显示设置
在所述 BIP21 规则中，amount 参数使用 BTC 单位；label 和 message 可表达标签与说明，这些文本不会因此写入实际交易。
这意味着界面显示单位与 URI 参数单位需要区分。标签也只是请求中的描述文字，不能单凭一个商户名称或订单说明，就确认收款方身份。其他方案的字段与单位应按各自规范理解。
误区四：符合 URI 语法就能被所有钱包打开
通用语法解决的是结构如何表达，钱包支持情况决定软件能否处理具体方案及参数。字符串在语法上成立，并不等于所有钱包、浏览器或操作系统都能解释它。
同样，URI 不必是可打开网页的网址。某些支付 URI 由关联的钱包应用处理；能否唤起应用与地址本身是否有效，是不同问题。
误区五：打开请求就代表支付完成或来源可信
解析 URI、展示请求、授权支付与完成交易属于不同阶段。出现预填信息的界面，不足以证明交易已经发生。
URI 的结构也不自动提供身份认证。地址、参数与标签各自表达有限的信息；格式正确、二维码可读或描述完整，都不能单独证明请求来自其声称的收款方。