analyzepsbt如何判断下一步？

PSBT卡住时，最危险的处理方式是把同一份文件反复丢给所有签名设备。Bitcoin Core 31的analyzepsbt提供更明确的诊断：它逐输入检查UTXO、脚本与签名材料，并给出当前最需要的BIP 174角色。先读missing和next，再决定补全、签名、合并或最终化。

先看每个输入是否具备签名上下文

inputs数组会报告has_utxo与is_final。如果has_utxo为false，Signer通常缺少验证前序输出和金额所需的信息；如果is_final为true，该输入已经有最终脚本或见证，不应再把它当作普通待签输入。

missing对象可能列出pubkeys、signatures、redeemscript和witnessscript。缺公钥不一定需要私钥，可能只是Updater尚未补入派生信息；缺redeemscript或witnessscript时，签名者甚至无法确认完整花费条件；缺签名则要检查对应公钥、sighash类型和设备策略。

missing项	优先动作	不应做的事
pubkeys	补公钥与派生信息	盲目导入私钥
signatures	找正确Signer签名	让无关设备重复尝试
redeemscript	从钱包策略补脚本	自行猜脚本
witnessscript	核对见证脚本与策略	只看地址外观

PSBT字段基础可参考BIP-174 PSBT字段怎么分类，Taproot相关字段则需结合BIP371如何核对Taproot PSBT。

next是角色提示，不是命令

BIP 174把流程分为Creator、Updater、Signer、Combiner、Input Finalizer和Transaction Extractor。analyzepsbt的next会指出整份PSBT下一步最需要哪个角色。例如缺UTXO或脚本时通常先Updater；已有足够上下文但签名不足时进入Signer；不同参与方各持一份部分签名时需要Combiner；满足花费条件后再由Finalizer生成最终输入，最后由Extractor得到网络交易。

Creator → Updater → Signer
                   ↘ 多份结果 → Combiner
                                  ↓
                           Finalizer → Extractor

真实流程可能往返，例如合并后发现某输入仍缺签名。不要把next当作“可以安全广播”的证明，只有完成最终化并再次核对交易内容后才进入提取和广播。

费用字段什么时候可信

当输入UTXO信息足够时，analyzepsbt可返回fee、estimated_vsize和estimated_feerate。缺少输入金额或脚本时，估算可能不可用。即使数值存在，也要确认输出总额、找零地址和单位，避免把BTC/kvB、sat/vB或显示层单位混淆。

签名前必须在可信设备屏幕核对收款输出、找零、金额和费用。可用PSBT签名前要核对什么做最终检查；如果目的是让节点补全现有PSBT，可参考descriptorprocesspsbt如何补全，不要把分析与修改混为一步。

一次可审计的排错流程

保存原始PSBT哈希；运行analyzepsbt并记录每个输入；按missing定位负责的钱包或设备；只补必要字段；再次分析；收集部分签名后用combinepsbt合并；确认next进入Finalizer；用finalizepsbt检查complete；提取前再次验证收款与费用。跨设备传输时要确认未知字段没有被丢弃。

若某输入长期缺少签名，应回到钱包策略确认门限、密钥指纹、派生路径和硬件设备状态，而不是修改输出绕过检查。任何包含私钥的操作都不应出现在联网日志中。

本文基于Bitcoin Core 31与BIP 174。工具只能说明数据结构是否足够，不能替你判断收款地址可信或交易目的正确。

多人签名要管理PSBT版本

多人协作时，每次更新都应生成新的PSBT版本并记录父版本哈希、操作者、加入字段和analyzepsbt摘要。不同签名者返回的文件先分别留档，再由专门的Combiner合并；不要在聊天工具中覆盖同名附件。合并后若交易输出、锁定时间或输入集合发生变化，应视为新交易重新走人工确认，而不是沿用旧审批。最终提取的原始交易还要与已批准PSBT的输出、费用和sighash策略比对，确保流程中的“数据补全”没有悄悄变成“交易重写”。

审批记录应与版本哈希绑定，任何参与者都能从最终交易反查到经过批准的那一版PSBT和完整变更链。