链级流量账本：getchaintxstats 的窗口字段和快照同步下的盲区

一、命令的骨架：一个可滑动的窗口

getchaintxstats 接受两个参数：窗口大小按区块数给，默认约一个月；结束点给区块哈希，默认链尖。返回的核心内容围绕这个窗口：窗口的起止高度与最终块哈希、窗口内经过的秒数、窗口内的交易笔数，以及一个平均每秒交易数 txrate。链上累计交易总数 txcount 是从创世数到窗口终点的总量。这些字段不是永远齐全——文档明确标注：窗口交易数和速率只有在窗口区块数大于零、且起点终点都存在交易总数时才有；换句话说，窗口选得太刁钻，返回里就会安静地缺字段，脚本要先处理缺省再计算。

二、一个容易被忽略的官方用例

发布流程文档里，每个大版本分支前要用 getchaintxstats 按 4096 个区块的窗口取样，用输出更新源码中的链参数统计量。选 4096 块约等于四周流量，平滑掉单周的拥堵和空白。想自己估算网络长期速率，照这个口径来比随手取七天要稳；七天窗口在节假日和行情低谷能给出误导性很强的低谷数字。另一个口径差异：txrate 是按窗口实际经过秒数算的，出块忽快忽慢时它会随之波动，不代表需求本身变了。

三、快照同步下的字段盲区

文档里有一句对用 AssumeUTXO 快速同步的节点很重要的话：txcount 可能未知。原因是这类节点从一份 UTXO 快照起步，历史区块没有逐块重放过，“链上至今多少笔交易”这个问题它答不出来。带这个节点做全网流量复盘之前，先用 getblockchaininfo 确认快照状态。窗口内统计不受此限制——只要起止高度之间的数据都重放或索引过，窗口计数照常工作，这也是为什么排障时优先用窗口字段而不是总量字段。

四、把它放回工具箱的正确位置

和邻近工具分工：getblockstats 看单块的费用与体积结构，getrawmempool 看此刻谁在排队，estimatesmartfee 看费率建议，getchaintxstats 管的是”多时间尺度上的平均流量”。典型用法三例：其一，用窗口交易数除以 4096 再乘每块空间上限量级，估平均单交易占用区块空间的粗粒度分布，判断自己那次转账是不是被塞进了一辆拥挤的班车；其二，按月记窗口数值，把”最近是不是更堵了”从体感变成曲线；其三，配合手续费数据交叉核对费率建议是否滞后。所有计算结果都应标注”示例非实时”——统计类数字随窗口每天漂移，引用旧数字冒充当下，是数据类文章最常见的失真方式。

补充：一组防错的调用习惯

三个防错习惯：取窗口数据永远显式给区块数而不是依赖默认值，因为”默认一个月”是实现细节，跨版本引用口径要先确认；解析返回前先判断 window_tx_count 是否存在而不是 try-except 蒙混，缺字段本身就是有意义的信号；把 txcount 与窗口值分开缓存——前者在快照节点可能永远不来，后者每天都在变，混在一个变量里迟早写出错账。数据管道里对”可选字段”的态度，基本决定了统计脚本的寿命。

最后是引用的规范：对外发布任何”链上平均交易速率”之类的数字，标注取数窗口（多少个区块、截止哪个高度或哈希）和取数节点是否用了快照同步，三者缺一，别人复算出来的就会和你不一样。窗口参数写进图表脚注的成本极低，事后对账的成本极高——所有链上统计类字段都吃这一条，getchaintxstats 只是最容易露馅的那个。