testmempoolaccept怎样预检交易？

testmempoolaccept 会让 Bitcoin Core 按当前节点的 mempool policy 预检原始交易，但不会广播。它适合在发送前发现手续费、冲突、脚本或链上输入问题；allowed:true 也不是未来一定上链的保证。

请求完整原始交易

    {"jsonrpc":"2.0","id":"preflight","method":"testmempoolaccept","params":[["0200000001...00000000"],0.10]}

第一个参数是原始交易十六进制数组，可测试有依赖关系的一组交易；maxfeerate 是费用保险上限，单位按当前 Core 文档解释。不要传 txid，节点需要完整序列化交易；示例中的 0200000001…00000000 只是格式占位，不能直接提交。

读取允许和拒绝分支

    [{"txid":"4a...","wtxid":"92...","allowed":false,"reject-reason":"min relay fee not met"}]

allowed:false 时先看 reject-reason。missing-inputs 要检查 UTXO 与父交易；txn-mempool-conflict 表示已有冲突花费；费用错误需重算 fee 与 vsize；脚本失败则回到签名和锁定条件。不要通过无限提高 maxfeerate 掩盖构造错误。

预检之后仍会变化

节点内存池、最低中继费率与祖先限制会变化，另一个节点也可能采用不同 policy。广播前在目标节点立即复测，并核对 effective-feerate 与本地计算一致。

对一组父子交易预检时，数组顺序必须让父交易先于依赖它的子交易，并同时检查每项结果和 package-error。allowed:true 的返回还可能包含 vsize 与 fees 等计算字段，客户端应与本地解码值比较；任一成员失败都不能只广播数组中的其余部分，除非业务明确允许拆包。

Bitcoin Core testmempoolaccept：把事实放回实际场景

testmempoolaccept在不广播交易的情况下测试节点当前内存池策略，返回allowed以及拒绝原因、vsize和费用等信息。
策略接受不等于交易已经进入网络或一定确认；策略拒绝也应与共识无效区分，并保存reject-reason与package-error。
结果依赖节点当前UTXO、mempool、费用策略和版本，同一原始交易在另一节点或稍后时刻可能得到不同结果。（有限确认）

保存Bitcoin Core testmempoolaccept记录时别漏这些字段

保留对象标识、网络、版本、访问时间，以及预检请求、allowed结果树、策略与共识对照的原始输入输出。截图辅助说明，结构化字段用于重放。

Bitcoin Core testmempoolaccept：先确定本页覆盖什么

顺序	核心问题	可执行目标
1	预检请求	用预检请求直接回答搜索意图并形成可执行核验信息。
2	allowed结果树	用allowed结果树直接回答搜索意图并形成可执行核验信息。
3	策略与共识对照	用策略与共识对照直接回答搜索意图并形成可执行核验信息。
4	时点差异	用时点差异直接回答搜索意图并形成可执行核验信息。