先预演再签字：simulaterawtransaction 能替钱包算出什么账

一、一个只回答一个问题的小命令

simulaterawtransaction 的返回结构简单到只有一个字段：余额变化，官方文档注明负数代表减少。你把一串原始交易十六进制交给钱包，它检查哪些输入花的是本钱包的钱、哪些输出回到本钱包，算出差额返回。命令不广播、不签名、不改变任何状态，是一台纯只读的计算器。它的价值不在信息量，而在”签字前的那一眼”——尤其在多签协作或脚本签名器的流程里，给签名方一个独立的、不依赖发起方的算法复核。

二、典型用法：签名前与签名后各跑一遍

流程上最扎实的用法是用两次。第一次在签名前：拿到对方给的待签交易，先跑一次，确认钱包视角的净支出和 PSBT 声称的一致——这一步拦截的是”文档金额与实际输出不一致”这类结构性差错。第二次在最终签名后、广播前再跑一次，确认最后一次加工没有偷偷改过内容（换找零地址、加输出）。两次数值相等，交易在钱包视角就没被动过。多签场景里，每个签名者都应独立跑自己的这份账，而不是信任协调人的转述。

三、它看不见的账

余额变化只是一个净额。命令不会回答：手续费付了多少（那要从输入总额减去输出总额推）、哪笔 UTXO 被花了、隐私上会暴露哪些聚类、费率够不够进块。它也假定交易与钱包的对应关系成立——若交易引用的是外部密钥的输入，这部分对钱包不可见。把它当对账器而不是审计器：它校验”这笔交易动了我的多少钱”，其余问题各有专门工具，例如费率估算、未花费输出查询、交易解码。

四、放进自动化流程的建议

给脚本作者的提醒：把该调用做成签名流程的强制门而不是可选提示，两次结果不一致就中断并留日志；返回值是浮点显示金额，比较时用精度容忍，别做等值硬比较；交易里含非钱包相关的额外输入时，预期差值应与构造方口径对齐，避免误杀。多签软件如果内置”每位签名者本地展示净额”的功能，底层逻辑与本命令同源——每个签名者手里的账本，是最后的安全边界。

五、小结

小额高频的日常支付用不上这道工序；但凡金额大到让你犹豫，或者流程里出现你不完全信任的中间方，先预演再签字就是成本最低的一道保险。

六、与相邻工具的接力关系

预演链条通常是三段：先解码交易看清输入输出全貌，再用费率估算判断这笔出价能不能进块，最后用本命令核对钱包视角净额。三者各答各的问题，顺序不可倒置——净额一致但费率过低的交易照样会滞销；费率漂亮但多出一个陌生找零地址的交易，则会在预演阶段就以差额暴露。把三段拼起来，才是一条完整的签字前流水线，单靠任何一段都有盲区。

七、边界案例的处理

两种极端：一是交易引用了非本钱包的额外输入，净额只反映钱包侧变化，和构造方给出的总额对不上属正常，先对齐口径再下判断；二是含燃烧输出的特殊交易，钱包把燃烧部分全额记为支出，净额看起来吓人却是预期结果，遇到这种数额异常先解码再看输出特征，比直接拒签更接近事实。工具只报数，判断仍然是人的工作——这句话在预演环节比在签名环节更重要。

风险提示：本文为钱包操作工具科普，不构成任何投资建议。