validateaddress 查不了归属：地址校验与钱包归属的命令边界

很多中文教程在教”怎么确认这个地址是不是你的”时，会同时提到 validateaddress 和 getaddressinfo 两个命令，然后给出一堆相同字段。这是历史遗留：两者早就分工明确，用错不但查不到答案，还会得出错误结论。

分界线是”要不要动钱包数据库”。validateaddress 是纯工具类命令，不做钱包归属查询。它回答的问题只有一个：这串字符在本链网络上是不是一段可解析、结构合法的地址脚本。在 v31.0 的 RPC 文档里，它的返回结构里已经没有 ismine、iswatchonly 这类字段——钱包相关字段早在 0.18 版本就被拆进了 getaddressinfo。留下的实用字段是 isvalid、address、scriptPubKey、isscript、iswitness，以及从 23.0 起新增的 error_locations。

error_locations 值得单独说。它返回的是”地址里出错字符的下标数组”，只对可定位的编码错误生效。官方文档写明了边界：对 Bech32 地址会尝试定位至多两处错误，且只有当替换错误少于两处时，结果的正确性才有保证。这意味着它适合做输入框的即时纠错提示——用户手抖把一个字符敲错，界面可以直接标出位置；它不适合用来”找出被改过的地址”，因为多处改动时它可能什么都不报。此外这个能力主要覆盖 Bech32/Bech32m 系列，老式的 Base58 地址不在同样的定位机制内。

要回答”这钱是不是我的”，只能问 getaddressinfo。它会查钱包数据库，返回 ismine（私钥在不在本钱包）、iswatchonly（是否只观察）、solvable（能不能解）、parent_desc（归属哪条输出描述符）、以及 labels。注意这两条命令的隐含代价差异：validateaddress 对任何节点、任何钱包状态都能跑，不会解锁钱包、不产生敏感查询痕迹；getaddressinfo 查询一个不属于本钱包的地址时不会泄露什么，但反复对大量地址调用它，等于在你自己的节点上建了一份”哪些地址属于我”的行为画像——如果这个节点同时对外提供 RPC，这就是隐私泄露面。

由此可以定出一条实操顺序。第一步只用 validateaddress 判断”能不能收”：一个 isvalid 为 false 的地址，无论它是你的还是别人的，都不该出现在转账界面上，因为节点无法为它构造输出脚本。第二步在确认结构合法后，才用 getaddressinfo 判断”归不归我”，并且只对本次交易涉及的少量地址调用。第三步是理解两者都回答不了的问题：地址结构合法不等于地址背后有可用私钥——一个随机生成但合法的地址，validateaddress 会说 isvalid: true，而链上永远没人能动它的钱；同样，ismine: true 也不等于”这笔钱安全”，它只说明私钥在这台钱包里，备份状态、派生路径是否记档是另一层问题。

开发者视角还有一条工程含义。收款界面常见的做法是粘贴即校验，如果实现者误用 getaddressinfo 做这件事，每次用户粘贴都会触发一次钱包数据库查询——在装有多个钱包、跑着同步的节点上，这是又快又没必要的负载；而且当用户粘贴的是别人家的地址（比如对账场景），查询返回的 ismine: false 毫无信息量。用 validateaddress 则是一条不碰钱包数据库的纯解码路径，开销小得多，还能顺带拿到 scriptPubKey 用于后续的构造。反过来，钱包恢复向导里确认”这些地址是不是你的”时，则必须走 getaddressinfo，用 ismine 与 solvable 组合判断——用错命令的后果是静默给出错误答案：一个你完全陌生的地址，validateaddress 也会客气地回一句结构合法。

顺带记录两个版本的坑。0.18 那次拆分在当时的发布说明里列出了全部迁移字段：ismine、iswatchonly、script、hex、pubkeys、sigsrequired、embedded、iscompressed、label、timestamp、hdkeypath、hdmasterkeyid 全部从 validateaddress 搬进 getaddressinfo——手上还留着 0.18 之前教程或代码片段的集成方，读到这份清单就能解释为什么旧字段在新节点上全部读空。另一个坑在钱包命令侧：getaddressinfo 对不属于本钱包的地址同样会返回结构信息（它不向外查询也不广播什么），安全上无碍，但若节点开了 RPC 调试日志（logging 里的 rpc 类别），这一串查询会被逐条记录在案，对隐私敏感的运营方值得知道这个痕迹存在于哪一层、默认不开启。

顺带处理一个常见误解：跨链复制粘贴时，主网节点解析 tb1 或 bcrt1 开头的地址会返回 isvalid: false，并给出网络不匹配的提示——Base58 时代同样如此，版本字节与校验和一起把网络写死在字符串里，测试网地址在主网节点上会直接解析失败。所以”发错网络”类事故的主战场不在这条校验命令上，而在两个它管不着的地方：一是收款方同时提供多条链的充值地址、用户复制错了那一栏；二是剪贴板被替换、粘贴内容与展示内容不一致。两道命令都只回答自己那一问，把第三问——“我到底该付到哪条链”——留给操作者自己确认，这也是正规钱包在发送前会把网络标识、金额与地址尾段再单独展示一次的原因。

风险提示：本文命令行为与字段以 Bitcoin Core v31.0 官方 RPC 文档为准，历史版本字段集合不同；不构成投资建议。