卡住的交易连着一条链：用 ancestors 与 descendants 把依赖摸清楚

先建立一个直觉：交易会排队

矿工按费率挑交易，但有一类排序不是交易自己说了算：一笔子交易要生效，必须先有它的父交易被打包。父交易费率低时，矿工的合理策略是”要么父子一起收、要么一个都不收”。于是你的高费子交易可能被一公里外的低费祖父交易拖住。排障时最忌讳把它当孤立问题处理，第一步应该是看清它站在谁的上面、上面压着谁。

两个 RPC 的方向与返回

getmempooldescendants 回答”这笔交易之后还有哪些子交易挂在它身上”，getmempoolancestors 回答”它要先付出哪些父交易”。两者都接受哈希和第二个布尔参数：参数为真时返回完整的交易对象，为假时只返回哈希列表。排查阶段先拿哈希列表画依赖图，再用完整版逐笔看大小与费用——父交易往往不是你发起的，那它的大小、费用、脚本结构都要单独读，不能想当然。

另一个轻量入口是 getmempoolentry 的 depends 字段：只给直接父交易，不给整棵树。它适合快速判断”这笔交易有没有依赖”，而两兄弟 RPC 才给你全景。注意这些方法都只覆盖内存池：一旦父交易确认，依赖链自然解散；全被打包后，你的子交易也就跟着上链了。

整包费率才是定价真相

决定矿工收不收的不是单交易费率，而是”父加子整包的费率”。手工算法：把链上所有交易的费用相加除以所有虚拟字节相加。CPFP 的逻辑由此而来：你在子交易上多付一笔费用，整包费率上去了，矿工把整条链一起收走，等于你替别人排队的交易补了车票——前提是这笔加急值得。谁该为父交易加急买单在社区里从来没有共识，只有成本分担的算术。

排障顺序模板

1. getrawmempool 或区块浏览器确认”确实还在池里”，先排除纯界面问题。
2. getmempoolentry 看 depends：有依赖才进入下一步，没有就单独处理这一笔。
3. getmempoolancestors 拉全祖先列表，汇总整包大小与费用，对比当前网络费率分布，判断该用 RBF、CPFP 还是等。
4. 若选 CPFP：新交易花这笔子交易的输出，自行抬高整包费率；若选 RBF：确认自己这笔交易构造时可替换，重新广播更高费版本。
5. 解决后把祖先链截图或存原始 JSON 归档，低费率父交易常来自别人或旧流程，值得回溯源头修正默认参数。

依赖链是比特币内存池排障里最容易被忽略的一层，看懂这两条命令，大多数”明明费用不低为何不确认”就有了确定性答案。本文不构成投资建议。

两个数字帮你给整包定价

做 CPFP 决策时有两个来自节点配置的参考值值得先查：祖先数量上限与包大小上限（可分别在内存池配置和发行说明里核对当前版本数值，历史上长期是 25 个祖先与十万量级的包体积）。这两个上限决定了一条依赖链”最多能被一起带上车”的规模——链太长或整包太大，矿工软件可能根本不看你的包，此时无论子交易加多少费都无济于事，正确做法反而是等父交易自然进块。另一个实操细节：加急子交易的输出最好直接指向自己控制的新地址，金额可以就是原输出减去合理费用，这样整包费率立即生效；有些钱包把这一步自动化成”加速”按钮，本质都是同一道算术。理解了限额，也就理解了为什么社区反复建议：别让你日常使用的钱包留下长长的交易依赖链，碎片化和链式依赖是慢性手续费病的病根，偶尔加急是治标，归集整理才是治本。