bitcoin.conf 之外还有 settings.json：节点配置的两层账本

为什么数据目录里多了一个配置文件

不少升级多年的节点运营者都有过同款困惑：明明只编辑过 bitcoin.conf，数据目录里却冒出一个 settings.json，里面还躺着自己从没写过的条目。这不是恶意软件的痕迹：从 0.21 版本起，比特币核心开始在数据目录维护这个持久化设置文件（发布说明对应变更记录 #15935），用来存放程序运行期间产生的设置。换句话说，节点配置从此有了两层账本：人写的那本（命令行与 bitcoin.conf）和程序自己记的那本（settings.json）。

两层各记什么

经典层不用多讲：命令行参数与 bitcoin.conf 决定启动形态。新账本记的是「软设置」——GUI 或 RPC 在运行中改动的部分会写进 settings.json。发布说明给了一个最直观的例子：GUI 里加载过的钱包列表会存入数据目录下的 settings.json，它在启动时「增补」（原文用词 augments）命令行或 bitcoin.conf 里 -wallet= 指定的钱包；在 GUI 里卸载某个钱包，它会从这份列表移除，下次开机就不再自动加载。同一份说明还提到钱包自动创建策略的变化：核心不再静默创建缺失的钱包，只加载显式指定处存在的那些，找不到就打警告——配置文件因此变得更「所见即所得」。

优先级怎么理解

按 0.21 发布说明的措辞把握原则即可：settings.json 的内容是在命令行与 bitcoin.conf 之外的显式设置之上做增补，而不是覆盖它们。你在 conf 里白纸黑字写的东西，不会被某次 GUI 点选悄悄推翻；反过来，只在 GUI 里改过的开关，重启后靠 settings.json 记住，翻遍 bitcoin.conf 找不到它们是正常现象。需要把某个运行时设置永久固定下来时，正确做法是把它补写进 bitcoin.conf，让它回到人可读、可版本管理的层。

排障的正确顺序

0.20 起有一项对排障极友好的改动：节点启动时生效的各项自定义设置会统一写进 debug.log。从此「我改了配置吗、改生效了吗」不必靠记忆和玄学——启动阶段直接查日志里打印的设置清单，和你的 conf 逐行对照。由此衍生三条纪律：一，改完配置必须重启才核对，日志没出现你的条目就要检查拼写与配置文件是否被正确路径加载；二，settings.json 建议只在节点停止时人工触碰，运行中手改可能在下一次程序写入时被原样覆盖；三，同一台机器上多份 bitcoin.conf（不同 datadir）很容易让人对着错误的文件改参数，启动日志里的路径信息顺手确认一遍。

迁移与备份提示

settings.json 属于你的数据目录状态，备份节点配置时请连同 bitcoin.conf 一起打包；还原到另一台机器时，两边文件都要核对，只恢复 conf 会丢掉 GUI 时期积累的运行设置（比如钱包加载列表）。团队协作或脚本化部署环境里，更稳妥的做法是全部配置走 bitcoin.conf，让 settings.json 保持接近空文件，任何一台机器都能从同一份文本复现出同样的节点行为。

这个文件能不能手改、要不要进版本库

结构上它是普通 JSON 文本，节点停止运行后可以直接编辑，但请把它当程序状态而不是配置清单：它的使命是记住运行时决定，人工长期维护它等于和程序抢笔记本。备份策略上，bitcoin.conf 是意图（intent），settings.json 是履历（record），两者一起才构成完整的节点身份，缺一不可。自动化部署环境里有一条被反复验证的经验：把所有设置显式写进 bitcoin.conf，让 settings.json 保持接近空，任何一台新机器从同一份文本启动都能得到行为一致的节点；反之，依赖 GUI 攒出来的 settings.json 做配置基线，等于把生产环境的关键参数藏在一份没人 review 的运行时文件里，故障时最容易被漏查。

风险提示：本文以对应版本发布说明为准，跨版本行为可能有差异，请以你所装版本的官方说明核对；错误配置可能带来带宽、隐私或钱包可用性影响，本文不构成投资建议。