裁剪节点还能查哪些历史数据？

“节点已经同步到最新高度”与“节点保存了全部历史区块文件”是两件事。裁剪节点仍验证区块链并跟随链头，但会删除一部分旧区块和撤销数据。历史查询能否成功，取决于所需原始数据、索引和实际保留范围，而不是一个笼统的“可查或不可查”。

三个字段先确定运行模式

getblockchaininfo返回pruned；启用裁剪时还返回pruneheight，并在自动裁剪时返回automatic_pruning和prune_target_size。

pruned为false时，当前节点没有启用区块文件裁剪；为true时才应读取pruneheight。automatic_pruning与prune_target_size描述自动裁剪目标，不应在未启用对应模式时被监控程序强制要求。解析器应按条件字段建模。

监控看板至少展示链名、blocks、headers、initialblockdownload、pruned、pruneheight和采样时间。只有高度同步且不处于IBD，才能进一步讨论历史可用性；否则查询失败也可能来自节点尚未追上。

pruneheight是当前仍未裁剪的第一个区块高度，之前区块的本地区块文件可能已删除。

pruneheight表示当前仍未裁剪的第一个区块高度。它不是“最后一个已删除区块”的模糊估计，也不代表此前所有派生信息都从每个数据库消失。最稳妥的解释是：早于该水位的本地区块文件可能不可供需要原始区块的RPC使用。

请求类型	水位线之后	水位线之前	额外条件
当前链状态与链头	通常可用	不按逐块回放查询	节点已同步
原始区块与完整交易	可按保留情况查询	可能缺少文件	目标块仍在磁盘
交易输入prevout	受undo数据支持	更容易缺失	最佳链且undo可用
独立索引派生结果	看索引状态	不保证完整	索引类型与建库历史

不要从表格反推出所有部署都一样。钱包数据库、txindex、外部索引器和备份系统可能保留额外数据，也可能从未完整建立。每项能力都要用真实RPC样本验证。

getblock verbosity 3的prevout只在当前最佳链且undo信息可用时返回，裁剪会限制历史明细。

getblock的verbosity 3希望为交易输入附上prevout，这需要比普通交易对象更多的历史上下文。只有目标位于当前最佳链、区块未被裁剪并且undo信息可用时，字段才有保证。把verbosity从2提高到3，不会凭空恢复已删除的数据。

因此面向审计的索引任务要在裁剪发生前提取所需字段，或把工作交给完整归档节点。若只是验证当前链并广播本钱包交易，裁剪节点仍可能完全满足需求。容量节省与历史分析能力之间应由业务需求决定。

size_on_disk是区块与undo文件的估算占用，不等同于整个数据目录或底层卷的实时可用空间。

size_on_disk用于观察区块与undo文件的大致占用，却没有覆盖整个数据目录中的数据库、索引、日志、钱包和操作系统开销。它也不等于文件系统free bytes。容量告警必须同时采集底层卷总量、可用量、inode和其他目录增长。

prune_target_size是目标值，不应被理解成绝对硬上限。同步、重组、临时文件和执行时机会造成短期差异。运维策略要保留安全余量，并在低空间时减少风险动作，而不是直接删除blocks目录。

对每个业务任务写出最老查询高度、所需RPC、必需字段、最大恢复时间和替代数据源。例如充值对账可能需要钱包事件与交易确认，链上分析可能需要全部原始交易与prevout，两者不能共用一句“节点可查历史”。

随后选择若干位于pruneheight之前、附近和之后的区块做探针，保存成功或失败结果。升级、重新索引、修改裁剪目标后重复测试。若使用远程归档节点，校验网络、链、区块哈希和访问权限，避免在故障时才发现备用源不可用。

需要扩大保留范围时，应评估重新下载、从可信快照重建或切换归档节点。随意从别处复制零散blk文件可能造成索引与数据不一致。执行前记录钱包备份、配置、索引类型和回滚路径，并先在隔离环境验证耗时与容量。

运行裁剪节点前先写清业务真正需要回查的高度、字段与恢复时限。只要需求超过本地保留边界，就应配置独立归档来源，而不是等查询失败后临时补救。

复核本文时请从Bitcoin Core 31 getblockchaininfo、Bitcoin Core 31 pruneblockchain、Bitcoin Core 31 getblock开始，并检查访问日期与版本。

当前不能越过的事实边界是：索引配置、外部归档节点和钱包数据库可保留额外历史，需按部署单独盘点。

相关背景可继续查看verifychain、getchainstates、getindexinfo。本文用于技术信息与教育，不构成投资、法律或个案处理建议。