getindexinfo如何判断同步？

getindexinfo 同时给出索引是否同步和最佳区块高度。本文用联合判定表区分“已配置、正在构建、追到旧链头、当前可用”四种状态，并给出业务探针与交接记录模板。

许多故障来自一个过早结论：“配置文件里开了 txindex，所以查询应该可用。”索引启动后还要构建并追赶链头；节点重启、重新索引或链头推进时，配置、存在、同步和业务可用是四个不同层级。

读取对象，而不是只取布尔值

getindexinfo返回节点当前运行的一个或全部可用索引状态，也可用index_name参数只筛选指定索引。

如果传入 index_name，返回对象可能为空。空对象应解释为“当前节点没有报告该索引”，而不是 synced=false。批量监控时同时查询全部索引，有助于发现配置名称或版本变化。

synced 与 best_block_height 要联合看

每个索引对象包含synced布尔值与best_block_height；配置中出现索引名称不等于索引已经追到当前链头。

状态	synced	best_block_height	判定
索引缺失	无对象	无	未启用、名称错误或版本不支持
构建中	false	持续上升	等待并观察速率
停滞	false	长时间不变	检查磁盘、日志和节点状态
已同步	true	接近本地链头	进入业务探针

即使 synced=true，也需要理解它对应的是本地节点视图；节点本身若落后全网，索引只是在追上一个落后的链头。

把链头作为第二坐标

判断可用性应同时比较synced、索引高度和getblockchaininfo报告的本地链高度；链头继续前进时短暂高度差需要结合采样时间解释。

index_height = getindexinfo[index].best_block_height
node_height  = getblockchaininfo.blocks
header_height = getblockchaininfo.headers

索引高度与 node_height 对齐，说明它追上本地已验证区块；node_height 与 header_height 或独立节点仍有差距，则问题在基础同步层。告警要指出差距发生在哪一层。

状态机会怎样变化

新启用索引通常经历缺失或初始化、构建中、接近链头和同步完成。链头继续前进时，短暂高度差可以接受；长时间无进展则需要结合 debug.log、磁盘容量、I/O 与进程状态调查。不要因为一次采样 false 就自动重启，重启可能让大索引恢复更慢。

业务可用还差最后一步

txindex 同步后，用一笔已知历史交易执行最小查询；blockfilterindex 同步后，用小高度范围运行过滤器相关 RPC。这个探针证明的是实际调用路径，不只是后台状态字段。查询失败时保留错误原文，区分索引缺失、数据裁剪和参数错误。

需要适配的变量是：索引名称与可用类型取决于Bitcoin Core版本和启动参数，监控程序应允许索引缺失并把缺失与未同步分开告警。

运维交接单

记录节点版本、启动参数摘要、索引名称、两次间隔采样的 synced 与高度、节点 blocks/headers、磁盘余量、最小业务探针和最终处置。第二位操作者应能从记录判断“继续等待”还是“需要干预”。

来源与相关内容

Bitcoin Core getindexinfo：用于核对接口字段、返回语义和适用边界；访问于 2026 年 7 月 25 日。
Bitcoin Core getblockchaininfo：用于核对接口字段、返回语义和适用边界；访问于 2026 年 7 月 25 日。

可配合 getdescriptorinfo检查、钱包描述符、Bitcoin Core PSBT流程阅读。索引状态属于本地节点事实，不能脱离版本与链头长期复用。

getindexinfo如何判断同步的复核演练

在测试节点上观察一个索引从构建中到 synced 的过程，每隔固定时间保存 best_block_height、blocks 与 headers。复核者要指出差距发生在索引层还是基础链同步层，并在 synced=true 后执行一条已知业务查询。只有状态字段和业务探针同时通过，才能关闭告警。若索引名称缺失，还要验证版本与启动参数，不可直接按未同步处理。