reindex 与 reindex-chainstate：比特币节点两种重来的差距是一个索引

先来一张解剖图

比特币节点在硬盘上的账本分三层：原始区块文件 blk 系列，只追加不修改，是物理事实；块索引数据库，记录每个区块头的位置与链关系；链状态数据库，维护当前最佳链上每个未花费输出等逻辑状态。多数”节点坏了”的现象坏在后两层，而原始区块文件往往完好。启动参数里的两个重建选项，正是按这个分层设计的。

-reindex 的官方描述是：清空链状态与块索引，从磁盘上的 blk 文件重建，同时清掉重建所有已启用的可选索引；如果加载过快照同步的链状态，也会一并清掉，之后可通过 RPC 重新加载。-reindex-chainstate 则轻一档：只清链状态，保留块索引，从 blk 文件重放重建链状态。名字里少掉的那个词，就是两者全部的差别。

病灶与药方的对应

启动失败时，软件常在报错里直接提示”请用 -reindex 或 -reindex-chainstate 恢复”，这不是随便给的二选一。经验判别：链尖行为怪、余额不对、UTXO 集怀疑出错，先试较轻的 -reindex-chainstate，它不需要重新扫描每个区块在文件里的物理位置，多数情况下更快走完；块索引本身损坏、blk 文件移动过目录或校验链断裂，就要用完整的 -reindex。两种模式共同的硬前提是 blk 文件完整：重放的前提是物理账本还在。还有一条源码里写死的红线——修剪模式下 -reindex-chainstate 会被直接拒绝并提示改用完整 -reindex，因为修剪过的节点已经没有可重放的完整区块流。

代价与流程

重建期间节点不可对外提供服务，重放的耗时与机器性能强相关：机械盘、小缓存的机器可能按天计。动手前的固定流程：先做数据目录完整备份；确认磁盘余量足够重建索引的临时开销；检查是否开着 txindex、coinstatsindex 这类可选索引，它们会在重索引时一并重建，等于加时；若用了快照同步，记好快照重新加载的方法。跑起来之后用 getblockchaininfo 看 validationprogress 判断进度，别中途断电——中断可以重启续跑，但一次干净的重建永远比抢救半截重建省心。

修好了之后做什么

重索引跑完不代表事情结束。第一件事是核对 getblockchaininfo 的字段：blocks 追到全网高度、verificationprogress 到 1、warnings 无内容，三项齐了才算干净。第二件事是检查当初为什么会坏：磁盘 SMART 状态、内存错误日志、意外断电记录，找出病因再考虑开机自启与自动重启策略，否则同一块硬盘还会再坏一次。第三件事是给节点加一道体检节拍——比如定期跑一次 verifychain 的低成本档位，让数据库损坏在第一周就被捕获，而不是等到启动失败才发现。重索引最经济的版本永远是”不需要做的那一次”，而预防它的全部成本，只是一套说得过去的监控和一块靠谱的硬盘。

两种模式的共同盲区

还有一类问题两种重建都救不了：问题出在blk文件本身。文件被截断、目录被移动后路径没跟上、备份恢复时混入了另一台机器的文件，都会让重放到一半才暴露异常。判别手段朴素但有效：核对数据目录里blk文件的数量与总大小和同版本节点的常识范围是否相符，比对校验记录（若你维护过清单），再结合日志里断点位置。预防端则靠纪律：数据目录整体迁移前先停节点、完整拷贝、启动后先跑一遍完整性检查再接业务；备份永远备份整个目录的快照，而不是只挑几个看起来重要的子文件夹。链数据的世界里，半套备份等于没有备份。

本文仅讲解节点软件机制，不构成任何投资建议；链数据重建耗时且不可逆地覆盖本地数据库，操作前务必备份并先在测试环境演练。