修剪模式省的是什么、留的是什么
比特币核心节点的修剪模式（prune）解决一个很朴素的问题：完整历史区块文件已经大到很多家用设备装不下，但绝大多数使用场景只需要验证”现在”，不需要回读每一年。开启修剪后，节点仍然完整同步并验证每一条规则——它没有跳过验证，只是不再把老区块的完整原始数据留在磁盘上。省下的是区块文件（blocks 目录里那些以高度命名的数据），保留的是区块头链、索引数据与 UTXO 集合，因此余额计算、收付款、规则验证全部不受影响。区块文件如何组织可看 比特币节点数据目录里都有什么：结构、体积与损坏修复。
修剪后磁盘上还剩什么
可以按三个桶来理解：第一个桶是 UTXO 集（chains 目录下的链上状态数据库），它决定”哪些钱还能花”，修剪永远不会碰它，同步完成后这个库就有几百 GB 量级的压缩前体积；第二个桶是区块头，每个只有 80 字节，几十年的头加起来不过几十 MB，它是简化支付验证和重连校验的骨架；第三个桶才是被修剪的对象——近史窗口以外的区块正文。窗口大小因实现而异，原则是保留足够新的历史以覆盖重组深度并留出维护余量，旧数据在确认”不可能再被回滚”后按序删除。
修剪节点的三个能力边界
第一，它不再对等网贡献历史区块：别的节点向它请求老区块时会被拒绝，它仍是全功能验证节点，只是变成”只收不发的读者”。第二，RPC 的回溯能力受限：getblock 查老高度会报错，区块链浏览器的原始导出做不了，但按 UTXO 集合回答”这笔钱花没花”的查询照常工作，相关工具见 裁剪节点还能查哪些历史数据？ 与 pruneblockchain裁剪前要查什么？。第三，冷备份语义变了：修剪后目录不再是可独立重建全历史的归档，恢复要靠重新下载或快照。
用快照补齐老区块：assumeutxo 的组合玩法
修剪节点有一个常被忽略的退路：老区块数据如果哪天确实需要，网络里还有别的全节点持有副本，可以定向找回，这正是 getblockfrompeer 类工具的场景。更省时的组合是 assumeutxo 快照同步：先用可信快照直接铺出 UTXO 集合立即开始验证新块，再在后台异步补齐（或按需找回）历史区块，把”同步完成”的主观等待从数天压缩到数小时，安全边界的分析见 assumeUTXO同步安全吗？ 与快照进度接口 getchainstates如何看快照进度？。对只想跑一个自己收付款的验证节点的家庭用户，“修剪模式加足够内存”通常就够了；想做数据考古或给别人供块，才需要全历史方案。
小结
修剪模式省磁盘但不省验证：老区块正文删除，区块头与 UTXO 集合完整保留，节点验证能力不打折，代价是失去供块义务和原始历史回溯，需要时可以从网络找回或用快照重建。选择标准只有一条——你跑节点是为了自己验证，还是为了给别人提供数据。本文不构成投资建议。
决策速查
三个典型画像：只想自己验证收付、硬盘在 1 TB 上下的家庭用户，用修剪模式加默认配置即可，预留的修剪目标值建议在新区块体量的若干倍之上留出重组余量；需要跑浏览器后端、审计历史、给他人的节点供块的人，直接放弃修剪，同时用 assumeutxo 缩短首次同步时间；硬盘紧张又想保留”考古”可能性的人，可以修剪起步，老数据用 getblockfrompeer 按块高取回，磁盘峰值换平时的一次性占用。三种方案的共同底线：无论修剪与否，节点都是完整验证者，你不需要信任任何人。存储与目录细节可回看 比特币节点数据目录里都有什么：结构、体积与损坏修复。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。