getaddressesbylabel结果怎么读？

getaddressesbylabel最常见的程序错误，是按数组解析结果。它实际返回一个JSON对象：完整地址字符串是键，值对象里才有purpose。若使用Object.values而丢掉键，最终只剩一堆receive/send，地址成员表会在不报错的情况下全部消失。

输入是一个精确标签字符串

getaddressesbylabel要求一个label字符串并返回分配给该标签的地址列表。

标签可能包含空格、大小写或业务符号，调用时应使用RPC客户端的结构化参数，不拼接shell字符串。批量任务从listlabels取得原始标签名，并作为值传递；日志可记录哈希或转义后的标签，避免控制字符破坏格式。

返回是以地址字符串为键的JSON对象，而不是简单数组。

每个地址键对应的对象包含purpose，值为send或receive。

遍历时使用entries而不是values，输出每行label、address、purpose。JSON对象顺序不应成为业务语义；需要稳定diff时，在导出阶段按地址字典序排序，并保留原始响应供复核。

receive通常关联钱包收款地址，send通常关联发送地址标签。它们不是链上账户类型，也不限制地址只能发生某一方向交易。purpose更不能证明地址背后的现实主体、司法身份或资金来源。

业务系统将标签用作客户或供应商别名时，要维护独立主数据。钱包标签被改名、合并或删除，不应自动更改财务主体；相反，客户名称变化也不应在没有审计记录时批量覆盖钱包标签。

listlabels可先生成标签全集或按purpose过滤的标签集合，再逐个调用getaddressesbylabel。

先调用listlabels取得标签集合，再对每个标签调用getaddressesbylabel。这是两层循环，必须处理单个标签失败：记录error并继续或安全停止，不能用空对象替代失败结果，否则迁移报告会把RPC错误伪装成“标签没有地址”。

大钱包调用时设置并发上限，保存节点、钱包和lastprocessedblock。若导出期间有人修改标签，前后结果可能不在同一逻辑快照；生产迁移应暂停标签写入，或在结束后重新导出并比较。

从每种purpose随机抽取地址，用getaddressinfo核对该地址是否属于当前钱包、其标签和脚本信息。再从原始JSON人工选择几个键与导出表对照。只有脚本自己的导出与导入互相一致，不能证明两边都没有丢键。

地址类型、描述符和是否可签名属于另一层。一个地址出现在标签映射中，不等于当前在线节点一定持有私钥；watch-only或外部签名钱包需要分别验收。

至少比较标签集合、每标签地址集合、每地址purpose，以及无法导出的错误清单。行数相同仍可能是一条缺失加一条重复。对集合做规范化哈希，并保留源与目标差异明细，才便于审计。

单地址设备核对见walletdisplayaddress核验，钱包脚本来源见描述符审计，地址编码基础见比特币地址类型。本文用于钱包元数据和RPC开发，不构成地址所有权、身份归属或资产证明。

资料访问时间为2026-08-13。仍需保留的边界：purpose描述钱包中的用途，不证明交易对手身份或链上资金归属；业务映射仍需外部台账。