比特币节点的数据目录里都有什么：blocks、chainstate 与一堆 dat 文件的分工

一、一切从一个数据目录出发

比特币核心把所有持久化数据都放进同一个数据目录（datadir）。启动时日志会打印实际使用的路径，也可以用命令行参数改掉。以 Linux 发行版为例，不指定时默认落在用户主目录下的隐藏目录。这篇文章按默认布局逐个拆，版本偏旧的发行版个别文件名可能不同，以节点启动日志为准。

二、blocks：账本原件

blocks 子目录是整条链的原始区块，文件名形如 blk00000.dat，每个文件写到约 128 MB 后滚动到下一个，区块按高度从低到高顺序追加。旁边还有一组 rev 开头的文件，存的是撤销数据（undo data），供链回滚时恢复被花掉的输出。开了剪枝（prune）的节点会删除旧区块文件里的原始数据，但保留区块头和索引，所以剪枝节点能对最新链给出正确验证结果，却无法再从头重扫全部历史交易。

三、chainstate：余额字典

chainstate 目录存的是未花费输出集（UTXO 集合）和链状态元数据，本质上是一个键值数据库。新节点首次同步的绝大部分时间，都花在把历史区块逐个重放、构建这本字典上。它和 blocks 的关系是：原件在 blocks，余额在 chainstate，两边必须指向同一条链，一旦错位，节点启动时会发现账本对不上并拒绝工作。

四、wallets：一个钱包一个文件

wallets 目录里，描述符钱包各占一个独立的 SQLite 数据库文件，文件名就是钱包名。早年那种把所有钱包塞进单个 wallet.dat 的 Berkeley DB 格式已经退役，旧文件需要先迁移。对普通用户来说，这是整个目录里唯一装着私钥的地方，备份优先级最高：丢了 blocks 可以重下，丢了钱包文件就找不回币。

五、mempool.dat 与三个 dat 配角

mempool.dat 是内存池的暂存快照：persistmempool 默认为 1，节点正常退出时写盘、下次启动时读回，读回时过期或已失效的交易会被逐笔重新验收。banlist.dat 保存黑名单条目，重启后仍然生效；peers.dat 是对端地址管理器的转储，记录节点攒下的可连地址；fee_estimates.dat 保存费率估算器的历史统计，删掉后节点要重新积累数据，短期内的费率建议会不准。这四个文件都是缓存型数据，损坏一般不伤及资产，但删了会让节点短期内表现得像失忆。

六、.cookie 与 debug.log

.cookie 是本机 RPC 鉴权用的随机令牌，同机的命令行客户端读它登录，目录权限就是它的边界——谁可读这个文件，谁就等于能调 RPC。debug.log 是日志，排障时第一个要看的就是它，日志里同样不会记录私钥，但也别把带路径的日志随意贴到公开场合。

七、备份清单一句话

值得长期保住的只有两类：钱包文件，以及你自己配置的 bitcoin.conf。其余文件全部可以重建，代价只是时间。

八、目录之外的两个易混项

有两样东西常被误当成数据目录成员。其一是下载压缩包自带的 bitcoin-xx.0 程序目录：里面是二进制与文档，和数据目录无关，升级版本换的是程序目录，数据目录原地不动。其二是发行说明反复强调的”程序不要跑在移动磁盘上”——数据目录放外置盘时，意外拔盘会在写入中途打断 LevelDB 与区块文件，轻则启动自检报损坏，重则钱包文件停在半写状态。目录路径、磁盘寿命、断电保护这三件事共同决定这套文件的可靠性，比记住每个文件名更重要。

九、排障时的读法

遇到节点行为异常，先按文件定位嫌疑层：区块下载停滞看 blocks 与日志；账本不一致看 chainstate（必要时评估两种重建方式的代价）；钱包余额对不上看 wallets 与重扫状态；重启后黑名单或记忆消失看对应 dat 是否可写、目录是否满了写不进去。整条链路的共同点是：这些文件都是可诊断的静态对象，任何”玄学故障”最后都能落回某个文件的读写状态上。

风险提示：本文仅为技术机制科普，不构成任何投资建议。