listlabels的receive和send怎么分？

listlabels看起来很简单：返回一串标签名。真正的坑在于把标签集合误当成地址集合，或把receive/send理解成交易方向。purpose描述的是标签关联地址在钱包中的用途；要完成迁移，必须先列标签，再逐标签展开地址，并另行核对金额。

不传purpose得到标签全集

listlabels返回全部标签名称，或仅返回分配给指定purpose地址的标签。

purpose参数可取send或receive；空字符串等同于不提供参数。

purpose只接受receive或send，空字符串等同于不提供。三次导出——all、receive、send——能形成集合关系：某个标签可能只出现在一侧，也可能因包含不同用途地址而出现在两侧。脚本不能假设两组互斥。

返回值只是标签字符串数组，不包含地址、余额或交易。

如果旧脚本把标签数组的每个元素当成地址去查区块浏览器，得到的错误甚至可能很隐蔽。正确流程是把标签名作为getaddressesbylabel的参数，再遍历返回对象的地址键。金额、交易和当前UTXO分别由其它接口提供。

默认标签可以表现为空字符串，导出到CSV时容易与缺失值混淆。建议增加is_default_label布尔列，并对空字符串做明确转义，不要在迁移时自动命名为unknown。

需要用getaddressesbylabel逐标签展开地址，并读取每个地址的purpose。

第一层记录label、是否出现在receive集合、是否出现在send集合；第二层记录label、address和purpose。保存源钱包名、格式、描述符状态、区块高度和导出时间。这样目标钱包导入后可按标签和地址两个层级比较。

若只迁移标签名而未迁移相应描述符或密钥，目标钱包不会因此拥有地址控制权。反过来，地址恢复成功也不保证本地标签元数据自动恢复。资产恢复、地址发现和标签迁移是三件事。

receive通常指钱包生成或使用的收款地址，send可用于外部发送地址标签。它不证明某地址现实中属于谁，也不代表该地址以后只能收或只能发。Bitcoin交易的输入输出仍由链上脚本和钱包所有权判断。

业务系统不要用send标签直接授权付款，也不要用receive标签直接证明客户身份。标签是可变的钱包本地元数据，应与客户数据库、审批和密钥控制分离。

迁移完整性先比地址成员，再对收款标签使用listreceivedbylabel或地址报表检查累计金额，最后用listunspent与getbalances核对当前状态。若金额不同，先对齐minconf、扫描高度和描述符范围。

修改标签前保存旧值和变更理由。大批量改名应先在副本演练，建立旧标签到新标签的映射，避免两个业务标签被错误合并成同一个字符串。

描述符基线见listdescriptors审计，地址设备核对见walletdisplayaddress核验，支付地址传递见BIP21支付URI。本文是钱包元数据管理指南，不证明现实身份、资产所有权或签名能力。

资料访问时间为2026-08-13。仍需保留的边界：标签是钱包本地元数据，不等于链上身份；同名标签的业务语义需由使用方自己维护。