拿到一串以 hex 编码的比特币交易，想知道里面到底装了什么：decoderawtransaction 是比特币核心提供的那台”解剖台”。它不需要节点同步任何数据、不查任何索引，把字节流拆开摊平还给你。但输入解析有个容易踩坑的开关，输出字段里有两个哈希长得像却不是一回事。本文按 v31.0 源码逐项核对。
一、它做什么、不做什么
源码里这条命令只有一个必给参数：交易的十六进制字符串。执行路径是纯本地的反序列化加字段展开，不访问区块数据库、不访问内存池、不要求 txindex，也不做任何共识校验——解码成功不代表交易合法，签名对不对、输入还存在不存在，它一概不管。想让节点先做语义预检，那是 testmempoolaccept 的活；想从链上反查一笔已存在的交易，那是 getrawtransaction 的活。decoderawtransaction 回答的问题只有一个：这段字节按协议格式拆开后长什么样。这使它成为离线环境里最安全的查看器：你甚至可以跑一个只开钱包不联网的节点，因为解码根本不需要网络。
二、iswitness 开关与启发式判断
第二个布尔参数 iswitness 决定按哪种格式反序列化。不传时源码允许两种解法都试一遍，靠启发式判断这笔交易有没有见证数据；传 true 只按见证交易解，传 false 只按非见证解。官方文档特意提醒：如果调用方本来就知道这笔交易有没有输入（比如来自链上的完整交易就该知道），把这个布尔显式传对，比让机器猜更稳。为什么值得较真？因为同一个十六进制串，按错误路径解出来的 txid 和 vsize 都可能错，而这个命令的返回里没有”我猜过了”的提示，猜错了也照样给你一个看似完整的 JSON。签名前的验单脚本、对账脚本建议永远显式传这个参数。
三、输出里两个哈希、三个体积
返回对象里 txid 是传统交易哈希，hash 字段装的是见证哈希 wtxid——对不含见证的老交易两者碰巧相同，对隔离见证交易则必然不同。内存池与孤儿交易库现代实现按 wtxid 记账，跨工具比对时先确认对方说的是哪一个。体积类字段给了三个：size 是含见证的总字节数，weight 是协议权重，vsize 是权重除以四向上取整的虚拟大小——算费率的基准是 vsize，别拿 size 去除费用。往下是 locktime、输入数组 vin 和输出数组 vout：每条输入带前笔交易的 txid 与输出序号 scriptSig 与 sequence，见证数据单独列在 txinwitness；每条输出带金额（单位是比特币而非聪）、序号 n 与 scriptPubKey 的汇编与地址解读。
四、典型用法与顺序
最常见的三个场景：其一，签名后的最终核对——把 PSBT 签完 finalize 出来的 hex 解一遍，肉眼过一遍金额、找零和手续费（fee 本身要靠你的输入输出账目相减，解码结果里没有 fee 字段）；其二，看别人贴来的半成交易，先解码再决定要不要签，跳过这一步等于盲签；其三，教学与排错，把 sequence、locktime 这些字段和协议文档对照。注意解码失败时的报错 TX decode failed 只说明字节流不符合反序列化格式，先检查 hex 串是不是被截断、是不是混进了非十六进制字符，或者就是 iswitness 猜错了解法。
五、边界清单
不会帮你算手续费；不会告诉你输入还能不能花；不会标记脚本是否标准；对 OP_RETURN 之类的数据只是如实展开，不裁决含义。把它当解剖刀而不是法官，用对了它就是你工具链里最不会撒谎的一环。
风险提示：本文只讨论交易结构与调试工具的使用，不构成任何投资建议；签名任何来路不明的交易前请先完整解码核对每一个字段。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。