AUG56 bitcoin body 253: estimateroutefee

闪电网络付款前，路由费是到付款那一刻才揭晓的黑箱吗？不完全是。LND 的 lncli estimateroutefee 提供一条探路命令：向目标发起真实的探测付款，把路由费用的下界先算给你看。它的名字里有 estimate，行为里却藏着一条容易误读的边界——返回值是下界，不是报价单。

两种输入方式，互斥不混用

命令的参数走两条路。第一条：--dest 给目标节点的三十三字节十六进制压缩公钥，此时 --amt 必给，且金额必须非零，单位是聪；少给金额命令直接报参数错误。第二条：--pay_req 直接给一条 BOLT11 发票字符串，此时不再需要目标和金额，节点信息、金额、路由提示都从发票里解出来。两个都传会报“只能设置其一”，两个都不传报“参数缺失”，CLI 在校验上不给模糊空间。用发票方式时还有一个 --timeout 旗标，给探测付款设一个截止秒数，默认值是六十秒；该旗标只对发票方式生效。发票的目标节点如果不在公开图谱里，命令会扫描路由提示，找一个公开节点作为探测的落点。

返回值为什么叫下界

协议定义写得很克制：routing_fee_msat 是以毫聪计的路由费估计下界。探测的本质是发一笔金额极小的付款穿过去，途中撞到哪些费率档、走没走和真实付款相同的路线，决定了这个数准不准。如果真实付款金额更大，途中通道可能流动性不足，路径会换，费用可能高于下界。第二个字段 time_lock_delay 给的是最坏情况的时间锁延迟估计，协议文档特别注明：调用方还要把最后一跳的 final_cltv_delta 加进去，返回的这个数不含它。第三个字段 failure_reason 指示探测本身成没成——成功时是 FAILURE_REASON_NONE，失败时会写明原因；探测失败不等于目标不可达，也可能只是这笔微额探测被中途策略挡了。

什么时候值得探一次

对普通付款，钱包自动路由，探测纯属多花一轮往返。值得用它的场景有三类。一是给固定收款方做预算：商户每天向同一节点付大额款，先探一次把费用下界和延迟量级摸清楚，再决定给自己的报价策略。二是自动化脚本在批量付款前做成本闸门：把 routing_fee_msat 换算成比例，超过阈值就改走链上或延后。三是排障对照：queryroutes 给出的是图谱内的假设路线，探测给出的是真实往返的结果，两者费用对不上时，往往说明图谱数据滞后或者途中的私有通道改变了报价。

探测的账本：花什么、省什么

它是一笔真实的付款尝试，走真实的HTLC、按真实费率付费，只是金额极小；timeout 默认六十秒的截止也只是终止付款循环的意愿表达，协议注释特别写着：截止的进程本身可能因为HTLC被拖延而超出这个时限。频繁探测会给路径上的节点制造流量负担，在流动性紧张的时段，探测失败率也会跟着波动。把它当温度计用，别当监控轮询用——每次批量付款前探一次是预算，每秒探一次是新的成本项。

与相邻查询工具的对照

queryroutes 在图谱内做假设推演，输出候选路线与其名义费用，不碰网络；estimateroutefee 用真实微付款穿过网络，拿到的是往返验证过的下界。两者的输出对不上时，差异本身就是信息：或图谱报价滞后，或私有通道在中间改过价，或目标前最后一跳设置了只对真实金额生效的流动性策略。自动化脚本常见的组合是先 queryroutes 筛形状、再 estimateroutefee 验成本，两道都过才放行批量付款。

风险提示：路由费用随网络流动性实时变化，探测值仅供参考，不构成对实际付款成本的承诺；本文是机制说明，不构成投资建议。