搭建一个比特币全节点，核心需要判断三件事：你的硬盘空间是否足够、同步速度能否接受、以及这个节点准备用来做什么。如果你只是想让钱包用自己的节点广播交易和验证收款，裁剪节点就够用，完全不需要准备 1TB 硬盘。裁剪节点仍然会下载并验证全部历史区块，只是验证完成后删除旧数据，安全性没有实质牺牲。
先想清楚：你要的是"归档"还是"够用"
在打开下载页面之前，先做这个判断，它决定了后面所有配置。
归档节点（Archival Node） 保存从创世区块至今的完整区块链数据。目前需要预留 600GB 以上的可用空间，且每年增长约 50–100GB。适合需要向其他节点提供历史区块、运行区块浏览器、或者做链上数据查询的场景。
裁剪节点（Pruned Node） 同样是全验证节点，会下载并检查每一个区块的每一笔交易，但验证完成后按你设定的限额删除旧区块数据。最低可以将区块数据限制在 550MB 左右，实际占用加上 UTXO 数据库、链状态等，通常建议预留 10–25GB。代价是：不能向其他节点提供历史区块，不能对旧交易做钱包重扫（rescan），也不能启用 -txindex 交易索引。
我的判断是：如果你的目标只是"钱包连自己的节点、不依赖第三方广播和查询"，选裁剪节点。如果你明确需要查询任意历史交易或运行 Electrum 服务器，再考虑归档节点。
下载与校验
Bitcoin Core 的官方下载页面在 bitcoincore.org/en/download。截至 2026 年 10 月，最新版本为 31.0。
选择对应操作系统的安装包。下载完成后，官方强烈建议校验文件的完整性。校验分两步：先核对 SHA256 校验和，再用 GPG 验证校验和文件本身的签名。Windows 上可以在终端里用 certUtil -hashfile 生成文件哈希，与官方 SHA256SUMS 文件中的记录逐字符比对。这一步不做也能运行，但如果下载过程中文件被篡改或损坏，节点可能行为异常。校验过程不复杂，值得花几分钟。
Bitcoin Core 支持 Linux Kernel 3.17+、macOS 13+（28.1 版本支持 macOS 11+）、Windows 10 及更新版本。
配置：裁剪、缓存和 RPC
Bitcoin Core 的配置文件 bitcoin.conf 位置因系统而异：Windows 在 %AppData%/Bitcoin，macOS 在 ~/Library/Application Support/Bitcoin，Linux 在 ~/.bitcoin。如果文件不存在，用文本编辑器创建一个即可。
决定裁剪大小。 在 bitcoin.conf 中加入 prune=10000，表示将区块数据控制在约 10GB。官方最小值是 550MB，但那个值只保留最近约 288 个区块（约两天），遇到链重组时重扫空间很紧。10GB 是一个更从容的起点，实际磁盘占用会在 15–25GB 之间，因为链状态数据库本身就有约 12GB 且持续增长。
分配数据库缓存。 同步速度最有效的优化是 dbcache。默认值约 450MB，对于现代机器偏小。如果你有 8GB 以上内存，设 dbcache=4096（4GB）；16GB 内存可以设 dbcache=8192。同步完成后，这个缓存占用会回落，不需要长期保留那么高的值。
开启 RPC 服务。 如果你打算让 Sparrow 或其他钱包连接这个节点，必须加入 server=1。这一行让 Bitcoin Core 接受本地应用通过 RPC 接口的连接请求。如果你只用 Bitcoin Core 自带的钱包图形界面，可以不加；但"用自己的节点配合外部钱包"这个常见需求，server=1 是前提。
如果需要从局域网另一台机器连接节点，还需要配置 rpcbind、rpcallowip 和 RPC 用户名密码。不要把 RPC 端口直接暴露到公网。
同步：预期多久，怎么看进度
首次启动后，Bitcoin Core 进入初始区块下载（IBD）。它会先快速拉取区块头（几分钟内完成），然后逐个下载并验证完整区块。
同步时间取决于硬件和网络：SSD + 16GB 内存 + 较快网速，大约 4–8 小时；SSD + 8GB 内存 + 普通宽带，12–24 小时；机械硬盘或低功耗设备，数天也正常。这不是故障，是比特币区块体积和验证工作量决定的。
用 bitcoin-cli getblockchaininfo 可以查看状态。关注两个字段：verificationprogress 表示进度百分比，initialblockdownload 为 false 时才表示真正同步完成。注意：区块头数量（headers）通常会比已验证区块数（blocks）跑得快，这是正常的，不要因为 blocks 暂时落后就以为卡住了。
如果进度长时间不动，首先检查网络连接是否正常。Bitcoin Core v25 之后对"慢节点断连"做了改进，自适应超时机制减少了因单个对等节点响应慢而反复断连的问题。另一个常见原因是磁盘 I/O 成为瓶颈，机械硬盘在这个阶段会明显拖慢速度。
连接钱包：Sparrow 的配置
把 Sparrow Wallet 连到本地 Bitcoin Core 节点，需要在 bitcoin.conf 中确认 server=1 已经存在。如果 Bitcoin Core 同步尚未完成，Sparrow 可能连上但无法正确扫描余额——钱包需要节点能提供完整的链上数据来查询地址历史。
Sparrow 连接本地节点时，RPC 配置通常不需要手动填写用户名密码（它使用 Bitcoin Core 的 cookie 认证）。如果节点在另一台机器上，则需要在 bitcoin.conf 中配置 rpcuser、rpcpassword、rpcbind 和 rpcallowip，并在 Sparrow 中填入对应的 IP 和凭据。
裁剪节点的一个实际限制：如果你的钱包是导入的旧钱包，Sparrow 可能需要让节点重扫区块链来查找历史交易。裁剪节点只能从它保留的最早区块开始扫描，更早的记录无法回溯。对于新建钱包或一直在用的钱包，这个问题通常不会出现。
风险与检查点
下载和配置阶段最值得注意的风险是下载了未经验证的客户端。不校验直接运行的后果可能是节点行为异常，极端情况下可能是资金安全问题。官方的校验步骤不复杂，建议至少完成 SHA256 校验和比对。
同步阶段不需要"守在那里看"，但注意磁盘空间变化。裁剪节点的实际占用会略高于 prune 设定值，因为链状态数据库是独立计算的。如果磁盘接近满，节点可能停止正常工作。
同步完成后，你可以用 bitcoin-cli getblockchaininfo 确认 initialblockdownload 为 false，然后在 Sparrow 中查看节点连接状态。此后你的钱包交易广播和地址查询都经过自己的节点，不再依赖公共服务器。
参考资料
- Bitcoin Core·Download - Bitcoin，页面未标明更新日期；核查日期：2026-10-08。
- Bitcoin Core Documentation·Running a Pruned Node，页面发布或更新日期：2026-03-02；核查日期：2026-10-08。
- Chainstack·How much does it cost to self-host a blockchain node in 2026，页面发布或更新日期：2026-09-21；核查日期：2026-10-08。
- Blockstream Help·Should I run a Bitcoin full node or a pruned node?，页面未标明更新日期；核查日期：2026-10-08。
- GitHub·studyknots running-a-node.md，页面未标明更新日期；核查日期：2026-10-08。
- Bitcoin Core Documentation·Initial Block Download，页面发布或更新日期：2026-03-02；核查日期：2026-10-08。
- Bitcoin Core·Bitcoin Core 30.0 Release Notes，页面发布或更新日期：2025-10-09；核查日期：2026-10-08。
- Bitcoin Core·Bitcoin Core 28.1 Release Notes，页面发布或更新日期：2025-01-08；核查日期：2026-10-08。
- Sparrow Wallet·Connect to Bitcoin Core，页面发布或更新日期：2024-06-25；核查日期：2026-10-08。
- Big Data Week·Running a Bitcoin Full Node: Practical, Opinionated, and No-Nonsense，页面发布或更新日期：2025-07-17；核查日期：2026-10-08。
- Jameson Lopp·Revisiting Bitcoin Network Bandwidth Issues，页面发布或更新日期：2023-08-04；核查日期：2026-10-08。
