getblock的verbosity怎么选？

getblock的verbosity并不是画质旋钮，而是四种不同的数据契约。档位越高，节点替调用方完成的解析和关联越多；应用拿到的字段更多，但响应、CPU、内存和历史数据要求也随之变化。正确选择应从消费端需求倒推。

四档返回值不是逐项加一点

verbosity 0返回序列化区块的十六进制字符串；1返回区块对象且tx仅含交易哈希。

verbosity 0返回整个序列化区块的十六进制字符串，适合需要自行解码、传递原始字节或核对编码的工具。verbosity 1变成JSON区块对象，交易部分仅列txid，适合区块目录、确认关系和轻量索引。

调用端必须按所选档位建立明确类型。若程序偶尔传0、偶尔传1，却用同一个对象解析器接收，错误可能在运行很久后才出现。日志里应保存blockhash、verbosity、节点版本和响应大小。

verbosity 2返回完整交易对象；verbosity 3进一步为输入附加prevout，但仅限当前最佳链的未裁剪区块且undo信息可用。

verbosity 2把tx数组扩展为完整交易对象，适合读取输入、输出、脚本和交易级字段。verbosity 3在此基础上为输入补充prevout，使调用方更容易计算输入金额或脚本来源，但它对当前最佳链、裁剪状态和undo信息有额外要求。

档位	tx表示	典型用途	主要代价或边界
0	原始区块字节的一部分	自行解码、协议测试	客户端承担全部解析
1	txid列表	区块目录、链头浏览	没有完整交易对象
2	完整交易对象	索引输出与脚本	大区块响应明显增大
3	交易对象加prevout	输入金额与来源分析	依赖最佳链与undo可用

若目标块位于分叉链，或节点已经裁剪所需撤销数据，verbosity 3不应被当作保证完整prevout的归档接口。生产索引器需要显式检测缺字段，并准备完整历史数据源。

Bitcoin Core 31在verbosity 1到3增加coinbase_tx元数据对象。

Bitcoin Core 31在verbosity 1到3的区块对象中增加coinbase_tx元数据。向前兼容的解析器应允许新增字段，并在业务需要时读取；旧客户端样本可能没有该对象，因此不能未经版本判断就设为全局必填。

升级测试应覆盖三个方向：31.0节点的新响应、旧节点的旧响应，以及应用尚未识别的未来字段。对象解析器忽略未知附加字段，核心字段缺失才硬失败；这样可以减少节点升级导致的无意义停机。

verbosity越高通常响应越大、解析成本越高，批量索引应按实际字段需求选择。

响应体量没有一个通用倍数。区块交易数量、脚本复杂度、节点存储和RPC并发都会改变耗时。上线前应选空区块、普通区块和交易密集区块分别压测，记录原始大小、压缩后大小、解析峰值内存和端到端延迟。

批量任务可把verbosity 1作为目录阶段，只对真正需要的区块提升到2或3。不要为了以后“也许有用”永久保存所有高档响应；先确定数据保留期限、字段使用者和重建成本。

区块浏览器首页通常先用1取得区块元数据和txid，再按用户点击单独查询交易；会计索引器使用2并自行维护UTXO或金额关联；一次性取证若需要prevout，可在确认数据条件后用3，并把缺失项列入报告。协议研究工具才更常需要0。

任务切换时不要沿用缓存而忽略档位。缓存键应包含链、blockhash、verbosity与节点数据版本；否则verbosity 1的轻量结果可能误命中需要完整交易的请求。

验收时确认参数类型、返回结构、最大响应限制、RPC超时、并发上限、裁剪状态和错误处理；抽查coinbase、普通交易、SegWit交易与多个输入的样本；模拟目标块不在最佳链和历史数据缺失。最后证明降级档位不会被业务误标为完整数据。

先列出业务必需字段，再选择最低可满足的verbosity。这样既减少传输与解析负担，也能让裁剪、版本变化和索引异常更容易被识别。

本页依据Bitcoin Core 31 getblock、Bitcoin Core 31 Release Notes、Bitcoin Core 31 getrawtransaction构建，不用二手摘要替代协议定义。

当前不能越过的事实边界是：响应大小与耗时取决于区块交易数量、节点磁盘和RPC并发，不给出统一性能阈值。

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