setlabel 改的只是这台机器的记事本：标签存在哪、谁会看到

钱包 RPC 里的标签体系常常被寄予超出实际的期待：给地址打上”交易所提币""工资”之后，用户以为标签会被网络记录、换台机器还能同步。实际上 setlabel 改写的只是这台机器上这个钱包文件里的一个本地映射。本文按 v31.0 源码拆解标签存在哪里、命令如何判定”这条记录算收款还是付款”，以及标签与流水查询、余额过滤的联动关系。

标签的存储与归属判定

setlabel address label 的实现只有三步：解码地址、读取标签字符串、写入地址簿。关键分支是归属判定——源码用 IsMine 检查地址是否属于本钱包：属于，就以”收款”用途写入地址簿；不属于，以”付款”用途写入，含义变成”这是我付过的对手地址”。两种情况下写入的都是钱包的数据文件，标签从来不是交易字段，链上没有任何位置存放它，网络其他节点也永远不会知道它的存在。由此推出三个确定的行为：备份文件丢失标签随文件走；同步到另一台节点靠的是钱包文件整体迁移，不是链上恢复；删除钱包重载后标签不复发。源码里 LabelFromValue 还处理了空串与缺省的归一化——空串与未设置在某些查询语境里都会被折叠成同一个默认桶，做过滤逻辑时不要把”无标签”与”标签为空串”当成两个类别。

标签如何渗进流水与余额

标签的第二层作用是查询联动。getbalances、listunspent、listreceivedbyaddress、listtransactions 都接受 label 参数做过滤，数据源就是地址簿里的地址到标签映射：流水里的 label 字段是查询时按地址反查地址簿现算的，不是交易记录里存的。这个机制有一个容易被忽略的推论——先有交易后有标签：入账之后才执行 setlabel，历史条目会立刻”追溯”上新标签；换掉标签名，历史报表随之整体改写。把它当审计线索的人需要警惕：标签是可以无限次重命名的弱证据，与交易哈希、地址十六进制的强标识完全不是一个量级。重要的收款关系应该用”地址本身”做主键，标签只做人类可读的别名。

与账户体系的历史边界

早年的 getaccount/setaccount 时代，“账户”是钱包原生的强隔离单位；标签体系取代账户后，隔离强度显著下降——标签不划分余额池，只划分视角。两个标签共享密钥库、共享 UTXO 选择：listunspent 按标签过滤出的”这个标签下的 UTXO”，在实际支出时会被钱包的自动选币混用，付”A 标签”的钱可能花掉被标记为”B 标签”的币。想让标签同时充当会计隔离单元，要么多钱包文件物理隔离，要么在应用层自建 UTXO 归属账本，不能指望 setlabel 达成。

一套可靠的记账姿势

综合源码行为，可靠的本地记账流程是：用地址当持久主键（十六进制字符串，永不改），标签当展示别名（随时可改不影响正确性）；导出报表时按地址聚合并同时打印当前标签快照；标签变更维护本地操作日志，因为钱包文件本身不记录”谁在什么时候把哪个地址改成什么标签”。隐私侧也有一句提醒：标签泄露的是你自己的记账习惯，钱包文件与含标签导出文件都属于敏感数据，共享截图与日志前做脱敏。

风险提示：本文为钱包接口机制说明；标签可随意改名这一点涉及财务核对，请务必以链上数据为最终依据，本文不构成投资与税务建议。