一个问总额、一个问费率：lncli estimatefee 与 wallet estimatefeerate 的分工

闪电节点经常要给链上动作报价：开道、关道、把余额提回交易所、临时整理钱包。LND 把”估个费”拆成了两条命令，一条在 Lightning 服务上、一条在钱包 Kit 服务上，名字只差几个字母，回答的问题完全不同：lncli estimatefee 问”这笔付款总共要烧多少”，lncli wallet estimatefeerate 问”这个确认目标对应的费率是多少”。选错命令是新手最常见的时间浪费——拿着费率当预算、或者拿总额当报价去调参数。本文全部以 LND v0.19.0-beta 源码为准。

estimatefee：按真实收款人和金额试算总额

主命令注册在 cmd/commands/commands.go，用法是 estimatefee send-json-string [--conf_target=N]。第一个位置参数是一段 JSON 字典，键是目标地址、值是聪：形如 {"地址一": 数字, "地址二": 数字}，帮助文本给的就是这个形状。它背后调用 Lightning 服务的 EstimateFee，请求体除地址到金额的映射外，还带确认目标、最少确认数、是否可花未确认、以及选币策略四项。返回三个字段：fee_sat（这笔交易的总费用，聪）、sat_per_vbyte（折算后的每虚拟字节费率），以及一个已弃用的按字节费率字段。

因为输入是完整支付意图，这个估算会把选币结果算进去：用了几枚 UTXO、有没有找零输出、地址是哪种脚本类型，都会改变字节数进而改变费用。命令支持 --coin_selection_strategy（largest、random 或跟随全局配置），说明文档明确：指定策略会覆盖 lnd.conf 里的全局值。也正因为依赖选币，估算与实际执行之间可以出现偏差——若两次调用之间钱包余额被其他任务改动（例如后台正在做清扫或租约锁定了币），试算结果就不再代表下一笔真实交易。源码层面还有个已知限制：租约机制存在的意义就是防止多路任务同时挑中同一枚币，而估价与付款之间没有锁，想精确就自己在租约保护下调用。

wallet estimatefeerate：只问费率不问付款结构

钱包侧的命令在 cmd/commands/walletrpc_active.go，用法极简：estimatefeerate conf_target，一个整数位置参数，越界或小于等于零直接报错并弹帮助。它调用钱包 Kit 的 EstimateFee，返回的费率来自链后端——帮助文本特意说明费率来源取决于配置，可能是节点后端，也可能被外部 URL 取代。

它对用户不是直接吐 JSON 里的原始字段，而是本地换算后再打印：sat_per_kw（每千权重聪数）、sat_per_vbyte（每虚拟字节费率），外加一组中继地板读数 min_relay_fee_sat_per_kw 与 min_relay_fee_sat_per_vbyte。这组输出的形状透露了它的定位——不带任何支付意图，纯拿”目标块数”去敲估算器，因此同一目标在任何时刻重复调用结果稳定，适合脚本轮询费用水位、也适合把费率喂给自己构造的交易。但代价是没有总费用：知道每虚拟字节多少聪之后，还要自己乘上交易虚拟大小才能得到预算，而虚拟大小取决于你没告诉它的输入数量、脚本类型和签名数量。

怎么选用

有完整支付计划（地址和金额都定了）就用 estimatefee，它给的是预算，可以直接拿去和钱包余额、预算上限比较；只想知道当前市场费率、或者在做手动构造交易前的价格侦察，用 estimatefeerate，它给的是单价，且不受钱包余额状态干扰。一个常见的连锁误用是：用 estimatefeerate 的单价估一个粗略总额，再据此设费用上限，结果因为实际选币多挑了几枚碎币、字节数超预估，付款因低于最低要求被拒。稳妥的顺序是先用 estimatefeerate 看水位，再用 estimatefee 按真实收款结构拿总额，最后拿总额加余量去设上限。

两条命令都不改变链上状态、不占用币，但都不构成对下一区块成交的许诺：费率估算的输入是节点后端的近期观测，比特币网络本身也没有承诺性的确认时间。把它们当作读数器而不是预报器，是用对这两条命令的关键。

风险提示：本文为闪电节点费用估算机制科普，命令与字段以 LND 当前版本源码为准，可能随版本调整；估算值不构成费用或确认时效承诺；不构成投资建议。