闪电路由节点的账面越来越像一门小生意：进出的每一跳都有报价，月底想知道”这门生意赚了多少”，靠翻转发明细一条条加总太低效。LND 为这件事准备了一张现成的报表——feereport。它的名字容易让人以为只是费率表，实际上接口返回的是两半内容：每条通道的现行报价，加上交换层在过去一天、一周、一个月里实际收进的路由费收入。报价是”打算怎么收费”，收入是”实际收到了多少”，把这两半放进同一张表，正是这个命令设计的巧思。
报价半张表：每条通道一条记录
报表的主体是一个按通道展开的列表，每条记录带四个数字。channel_point 标明这是哪条通道的资金交易位置，chan_id 是同一通道的全局编号；base_fee_msat 是每笔经过的付款固定收取的基数费，单位毫聪；fee_per_mil 是”每一百万毫聪抽多少”的比例费率，同样是毫聪口径；fee_rate 则是把比例费率除以一百万之后的等效小数。读报价时最容易踩的是单位：fee_per_mil 数值 1 就是百万分之一（0.0001%），100 才是万分之一；很多人以为调了半天费率没生效，其实是把 50 当百分之五写进了策略。base 与比例两项的组合决定了不同金额付款的实际成本，小额付款基本被 base 吃掉，大额付款看比例，这也是为什么路由策略要按自己通道的常见流量形状去配。
报表是”节点全局执行”的口径：它展示的是当前对每条通道生效的策略快照，而不是你历史上配过什么。改过策略再查，看到的就是新值；想看旧值，得回访问日志或数据库，报表本身没有历史。
收入半张表：三档滚动窗口
紧跟在通道列表后面的是三个累计值：day_fee_sum、week_fee_sum、month_fee_sum，分别是过去 24 小时、一周、一个月里交换层收取的路由费总收入，单位聪。它们是滚动窗口而非自然日——“过去 24 小时”以查询时刻为终点倒推，不是”今天零点以来”。做经营对账时这个区别很关键：拿它和转发明细按自然日汇总去核对，永远差一截，正确做法是把窗口对齐查询时刻再求和。
三档数字还有个诊断用途：它们是对账的独立性交叉点。day 与 week 的比值异常（比如 day 突然超过 week 三分之一），多半意味着近一两天有异常流量或费率误设；week 与 month 走势背离，则常是通道结构变了——大通道被关掉或新开了一条高利用率线路。不用打开任何日志，三个整数就能给出第一层体检。
和相邻工具怎么分工
feereport 只管收钱侧的快照，付钱侧和明细各有别的命令：查每笔转发记录用转发明细接口，查自己付款花费用付款历史接口，查链上手续费则要看钱包层。报表级汇总与明细级账本的差别是聚合粒度——报表快但不可下钻，明细慢但可对每一笔。一个健康的运维节奏是：日常看三档收入做健康检查，数字异常时才去明细里定位通道与时间段。
最后一点单位纪律值得单独强调：闪电世界的报价默认单位是毫聪与百万分比，链上世界是聪每虚拟字节。在同一个仪表盘里混放两套口径而不在字段名里标注单位，是路由节点运营报表出错的第一大来源。feereport 的字段名把单位写进了名字里，这是接口设计的善意，也是读表人的责任——看到 base_fee_msat 就按毫聪读，看到 fee_per_mil 就按百万分比读，永远不要凭直觉换算。
风险提示：路由费率与收入描述仅为机制说明，路由收入受流量与竞争影响存在不确定性，本文不构成任何收益承诺或投资建议。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。