rescanblockchain怎样限定高度？

导入描述符后发现旧交易缺失，最直觉的动作是从创世区块全量重扫。但对运行多年的钱包，这可能浪费大量I/O；在修剪节点上还会直接失败。rescanblockchain的正确用法，是先证明历史区块可用，再把已知最早相关高度转换为一个留有余量的扫描起点。

这个RPC扫描的是当前钱包视图

rescanblockchain重新扫描区块链，查找与当前钱包有关的交易。

它不会给节点下载缺失区块，也不会替你导入脚本、密钥或描述符。扫描能找到什么，取决于调用时钱包已经知道哪些脚本。先导入再扫描，和先扫描后导入，结果并不等价。生产钱包还应先备份，并记录导入时间戳与描述符范围。

start_height默认0；stop_height可省略以扫描到链顶，返回实际扫描的起止高度。

如果知道钱包第一次可能收款的区块高度，不应恰好从该块开始。时间戳换算和区块索引可能有误差，建议向前留一段安全窗口，并把选择理由写进运行记录。返回的start_height与stop_height用于确认实际执行范围。

修剪节点只能从仍有区块数据的高度开始重扫，缺失的历史区块需要先补齐。

getblockchaininfo中的pruned说明是否启用修剪；pruneheight表示当前保留区块的最早边界之一。请求从更早高度扫描时，本地可能只有区块头而没有完整区块数据。此时RPC不能凭区块哈希恢复钱包交易。

处理办法不是反复重试，而是选用保留完整历史的可信节点，或按Bitcoin Core支持的方式补回所需区块数据后再扫。不要为了省事从pruneheight开始并宣称钱包已完整恢复，那只能证明该高度之后被扫描。

可用abortrescan中止正在进行的钱包重扫，并用getwalletinfo观察scanning字段。

getwalletinfo的scanning字段可帮助判断是否正在扫描及进度。调用期间减少其它重型钱包操作，记录节点高度、钱包名、描述符清单和开始时间。若自动化超时，先查扫描是否仍在后台继续，不要立即发起第二次重扫。

需要中止时使用abortrescan，并保存中止时点。中止成功不等于已经回滚此前发现的交易；后续恢复应重新选择覆盖重叠区间的起点，避免在边界处漏扫。

验收至少包含：返回高度覆盖预期区间；getwalletinfo不再显示扫描中；已知历史交易能由gettransaction或列表接口找到；关键地址和描述符仍属于钱包；钱包级余额与抽样UTXO能相互解释。

若交易仍缺失，按脚本是否导入、描述符range、时间戳、区块是否保留、钱包是否加载和交易是否确实上链逐层排查。盲目把起点改为0只是扩大成本，不会修复错误描述符。

钱包状态字段见getwalletinfo钱包状态，修剪可查范围见裁剪节点历史数据，导入流程见importdescriptors导入观察钱包。本文不替代私钥备份；只持有地址或标签也不能恢复签名能力。

资料访问时间为2026-08-14。仍需保留的边界：实际耗时取决于高度跨度、存储和钱包脚本数量，文章不承诺统一时长。