从源码编译比特币核心，报错信息里一大半的锅都属于”依赖不对”：编译器版本太老、Boost没装够、libevent缺了头文件。项目官方维护了一张依赖清单，把”要装什么、最低什么版本”写成了表格。本文把这张表（以v31.0源码树中doc/dependencies.md为准）逐行讲透：每项依赖是干什么的、哪些必需、哪些只是可选功能的钥匙，以及装不下旧系统时怎么办。
编译器：只认两条路
表格第一块是编译器：Clang最低17.0，GCC最低12.1，二选一。这比很多用户直觉要严格——发行版自带的老GCC常年落后两三个大版本，在Ubuntu 20.04这类系统上直接make大概率在C++标准的某条语法上折戟。表格每项都链向对应的上游PR，版本门槛是逐步抬上去的：项目只承诺在表内版本上测试过，新语法、新警告策略都可能让老编译器以匪夷所思的方式失败。这不是歧视老系统，而是C++项目控制兼容矩阵的标准做法。
必需依赖：三件套加一条运行线
构建期必需三项：Boost（最低1.74.0）、CMake（最低3.22）、libevent（最低2.1.8）。三者分工明确：Boost提供跨平台基础组件（迭代器、文件系统一类）；CMake是配置系统，负责把源码树翻译成你机器上的构建规则；libevent撑起RPC服务与事件循环——只要你想用bitcoin-cli，这个依赖就绕不开。运行时另有一条硬底线：glibc最低2.31。这一条对老系统用户最致命：CentOS 7之类的glibc 2.17发行版，连官方预编译包都跑不动，更别说自己编译——表里的glibc说的是运行节点的环境，不是编译环境，很多人把它当编译依赖查，查错了方向。
可选依赖：每一项对应一个功能开关
表的后半部分是可选清单，括号里标着服务对象，值得逐条翻译成人话：Cap’n Proto与libmultiprocess（表格标注最低0.7.1与v7.0-pre1）服务于多进程IPC模式，把GUI、钱包工具拆成独立进程与节点核心通信，普通用户无感；Python 3.10以上是跑功能测试与若干脚本用的，只编译不测试可以缓一缓；Qt 6.2对应图形界面钱包bitcoin-qt，纯命令行节点（bitcoind）不需要；qrencode是GUI里的二维码生成；SQLite（最低3.7.17）是钱包数据库引擎，从0.21代钱包文件迁移到SQLite后就一直是默认后端，不编译钱包模块才可不装；systemtap对应源码树里单独的tracing文档，是给性能研究者用的插桩钩子；ZeroMQ（最低4.0.0）让节点在新区块、新交易等事件上向订阅者推送通知，很多区块浏览器与商户后端靠它，需要就用apt装一个即可。GUI运行时还有Fontconfig、FreeType两条字体依赖，发行版桌面环境通常已带。
读这张表的正确姿势是倒过来用：先决定你要什么功能——纯节点、带钱包、带GUI、带ZMQ推送——再决定装哪几项，而不是照单全收。少装可选依赖不会让节点降级，只会让对应功能缺席。
依赖装不动时的第二条路：depends系统
老发行版装不到表内版本的Boost或Qt时，不必硬升系统。源码树的depends/目录内置了一套交叉/本地依赖构建系统：一条make命令按内置配方把所有第三方库编译进独立前缀目录，比特币核心再对着这个自足的依赖树构建，只依赖目标系统的glibc等基础层。它的默认用途是交叉编译（见depends/README.md），但同样可以为本机构建”自带干粮”的依赖集。代价是编译时间——全套依赖从头搓一遍，笔记本上一两个小时是正常心理预期。
编译之外，还要看清这页没写什么
这张表管的是”从源码构建”。大多数普通用户应该用官方预编译包：下载页的每个二进制都对应glibc不低于2.31的Linux等运行条件（版本对应关系以官网当期说明为准），装完即用，无需触碰编译器。真正需要自编译的三类人：要用表内可选功能组合的、跑非主流平台或指令集的、以及要改源码的。前者照表装依赖即可；后两者多半还会用到同一文档集里的build-unix、multiprocess与tracing等专页，这张依赖表只是它们的共同前提。
风险提示
本文以比特币核心v31.0源码树当期文档为准，版本门槛随上游策略持续上调，动手前先查你要编译的那个版本自带的doc目录，不要拿旧教程的版本号套新代码。编译环境与包管理器差异造成的个案报错，以构建日志与官方构建文档为排查依据；本文不构成任何性能或兼容性承诺。
发表评论
还没有评论，来说两句吧。
评论区为展示样式，提交不会被处理。