搭建闪电网络节点，真正麻烦的不是把软件跑起来，而是理解通道里的钱跟你链上钱包里的钱是两回事。节点软件本身十几分钟就能装好，但如果你把主私钥或者错误的备份文件当成"恢复凭证"，通道里的资金可能在你不知情的情况下被罚没。这篇按你实际要完成的任务顺序来说：先判断自己适不适合跑节点，再装软件、开通道、做备份，最后处理关闭和恢复。
先想清楚：你为什么要跑节点
跑闪电节点和用闪电钱包是两件事。用钱包（比如 Phoenix、Breez、Zeus 搭配现成节点）是花钱买便利；跑节点是你自己成为网络的一个路由点，自己管流动性，自己承担在线率和备份的责任。
如果你只是想收发闪电支付，更建议先用现成的托管钱包或 LSP 方案，少一层私钥管理，也少一个必须保持在线的负担。跑全节点适合这几种情况：你想自己掌控资金而不依赖第三方、你在做需要程序化收付款的集成、你想给网络提供路由流动性并赚取手续费，或者你单纯想搞清楚通道机制。
判断依据很直接：你能接受节点偶尔离线吗？你愿意定期检查通道流动性和备份文件吗？如果答案是否定的，托管方案是更合理的选择。
装节点：两种主流实现
目前中文社区用得最多的是 LND（Lightning Labs 出品）和 Core Lightning（原名 c-lightning，Elements Project 出品）。两者都是成熟的实现，选择上主要看你后续想用的工具链。
硬件和系统
LND 官方给出的最低配置是 2GB 内存、四核 1GHz 处理器、5GB 存储，但明确要求不能用 SD 卡，要用品质可靠的 SSD，因为 LND 会频繁读写。如果你同时跑 Bitcoin Core 全节点（推荐这样做），存储需求会大幅上升：Core Lightning 的文档建议约 500GB 空间。用修剪过的 Bitcoin Core 或者连接远程 Bitcoin 节点可以降到 5GB 以内，但修剪节点可能影响性能。
系统方面，Linux（尤其是 Debian/Ubuntu）是最省心的选择，Mac 和 Windows 也能跑，但 Windows 通常建议走 Docker。
Neutrino 模式：不跑全节点也能用
LND 支持 Neutrino 后端，这意味着你不需要运行 Bitcoin Core，节点会通过轻客户端方式同步链上数据。Lightning Labs 自己的演示中，用 Neutrino 模式在 2GB 内存的 VPS 上，从零到同步完成大约 15 分钟。
Neutrino 的代价是隐私和信任假设：你依赖 Neutrino 服务器获取区块头，对方可以看到你查询了哪些交易。如果你只是个人使用，这个折中通常可以接受；如果你对隐私要求高，还是跑自己的 Bitcoin Core。
配置要点
以 LND 为例，配置文件在 ~/.lnd/lnd.conf（Linux）。关键项包括：指定 bitcoin.mainnet=true、选择后端（bitcoin.node=neutrino 或 bitcoind）、设置别名 alias=<你的节点名>，以及建议开启 db.bolt.auto-compact=true 让数据库定期压缩。
Core Lightning 的启动更直接：确保本地 bitcoind 已同步完成且没有设置 walletbroadcast=0，然后运行 lightningd --network=bitcoin --log-level=debug。
通道：钱锁进去之后才真正开始
通道是闪电网络的基本单位。它本质上是一笔 2-of-2 多签的链上输出，双方各自持有一半私钥。开通道就是把链上比特币锁进这个多签地址，然后双方在链下交换签名过的"承诺交易"来更新余额分配。
开通道前要准备什么
你的节点钱包里需要有链上比特币。开通道时，你指定对手方节点的公钥和 IP/洋葱地址，以及通道容量。注意两个限制：链上手续费会从你的余额里扣，而且 LND 要求每个通道保留 10,000 聪的链上余额作为 anchor reserve，总共最多保留 100,000 聪。也就是说，如果你钱包里有 100 万聪，实际能用于开通道的可能略少。
一些对手方会设置最小通道容量。你在尝试开通道时如果容量低于对方要求，会收到提示。
流动性：开完通道你只能发不能收
这是新手最容易误解的地方。假设你用 100 万聪开了一个通道，初始状态下你的出站流动性是 100 万聪，入站流动性是零——你可以往外发最多 100 万聪，但一分钱都收不了。
要获得入站流动性，你需要让别人往你的通道里发钱，或者开一个双向出资的通道，或者从 LSP 购买入站流动性。流动性管理是运行路由节点的核心日常工作，不是一次性配置。
通道要几个确认才能用
LND 的通道通常需要 3 个链上确认才被视为打开可用。在此之前，通道处于 pending 状态。
备份：seed 不够，SCB 才是通道的保险
闪电网络节点的备份逻辑跟链上钱包完全不同。你的 aezeed seed 只能恢复链上资金和节点身份，不能单独恢复通道里的钱。如果你只备份了 seed，节点硬盘坏了，通道里的资金需要靠对手方配合才能找回，而对手方可能已经离线或不愿响应。
LND 的 Static Channel Backup（SCB）
LND 的 SCB 文件默认在 .lnd/data/chain/bitcoin/mainnet/channel.backup。这个文件包含每个通道对手方的信息和通道的初始状态。它的恢复机制不是从备份文件里读出余额，而是让新节点联系这些对手方，请他们广播最新的承诺交易来强制关闭通道，然后你从链上收回属于自己的那部分。
恢复命令是 lncli restorechanbackup --multi_file /path/to/channel.backup，执行前确保节点已经同步到链和网络图。恢复后资金通常很快到账，但不是所有对手方都会立刻响应——有的可能离线，官方文档建议等一两天，如果还没动静，可以尝试用对手方最新的 IP 或洋葱地址手动连接。
SCB 必须在每次开新通道后重新备份，因为它不会自动包含新开的通道。
Core Lightning 的 emergency.recover
CLN 的对应机制是 emergency.recover 文件，位于 $LIGHTNINGDIR（通常是 ~/.lightning/）。和 SCB 一样，它在每次开新通道后更新，需要手动重新备份。
恢复流程是：把有效的 hsm_secret 和最新的 emergency.recover 复制到新节点的 $LIGHTNINGDIR，启动 lightningd，然后运行 lightning-cli emergencyrecover。之后就是等待对手方强制关闭通道，节点会自动扫回资金。
这里有一个实际存在的坑：GitHub 上有人测试 CLN 的 emergency.recover 时发现，恢复后的节点需要链上资金来支付强制关闭的交易费，因为关闭交易需要广播到链上，而新节点钱包是空的。这意味着你恢复时可能需要先往节点钱包里转一点比特币。
不要用数据库快照恢复
CLN 文档明确警告：不要用 lightningd 数据库的快照来恢复。闪电网络的惩罚机制意味着，如果你广播了一个过时的通道状态（旧数据库里保存的），对手方可以用惩罚交易拿走你通道里的全部余额。数据库备份只有在你能确认它是最新状态时才有用，而实际中这很难保证。
退出：正常关闭和强制关闭
关闭通道有两种方式。合作关闭是双方同意后一起广播一笔结算交易，手续费通常更低，资金到账更快。强制关闭是单方面广播你手里的承诺交易，适用于对手方离线或拒绝配合的情况。
强制关闭后，你的资金不会立刻到账。你那一侧的余额会被 CSV 时间锁锁定一段时间（通常按通道大小动态设置，可能长达 144 个区块，约 24 小时），而对手方的余额可以立即花掉。
如果你在节点离线期间对手方试图广播旧状态作弊，watchtower 可以替你惩罚对方——但目前的 watchtower 是利他性质的，没有经济激励，而且你必须提前配置好。对个人节点来说，最实际的保障是尽量保持节点在线，并定期备份。
恢复的实际操作顺序
如果你的节点彻底坏了，手头有 seed 和 SCB（或 emergency.recover），恢复步骤是：
在新机器上安装同款节点软件，不要导入旧数据库。
用 seed 创建钱包，恢复节点身份。
等节点同步完成（
lncli getinfo显示 synced to chain 和 graph 均为 true）。导入 SCB：
lncli restorechanbackup --multi_file /path/to/channel.backup。等待对手方强制关闭通道，资金扫回链上钱包。
如果一两天后仍有通道未关闭，手动连接对手方节点。
没有 SCB 或 emergency.recover 的情况下，仅凭 seed 无法保证取回通道资金。对手方是否愿意配合、是否还在线，都会影响结果。
参考资料
- Zelcore·Lightning Network Explained: Channels, HTLCs, Routing，页面发布或更新日期：2026-04-19；核查日期：2026-10-13。
- Lightning Labs·Get Started | Builder's Guide，页面发布或更新日期：2026-02-01；核查日期：2026-10-13。
- Core Lightning·Set up your node，页面未标明更新日期；核查日期：2026-10-13。
- Lightning Labs·Demo: Litd Speed Run | Builder's Guide，页面发布或更新日期：2025-05-06；核查日期：2026-10-13。
- Lightning Labs·Running LND，页面未标明更新日期；核查日期：2026-10-13。
- Core Lightning·Running your node，页面发布或更新日期：2026-09-08；核查日期：2026-10-13。
- Lightning Labs·Lifecycle of a Payment Channel，页面未标明更新日期；核查日期：2026-10-13。
- Lightning Labs·First Steps With LND | Builder's Guide，页面发布或更新日期：2025-04-30；核查日期：2026-10-13。
- Lightning Labs·Disaster recovery | Builder's Guide，页面发布或更新日期：2025-04-30；核查日期：2026-10-13。
- Core Lightning·Backup your wallet，页面发布或更新日期：2026-01-13；核查日期：2026-10-13。
- Core Lightning·Wallet recovery，页面发布或更新日期：2026-09-23；核查日期：2026-10-13。
- Lightning Labs·How to Get Inbound Capacity on the Lightning Network，页面未标明更新日期；核查日期：2026-10-13。
- Lightning Labs·Watchtowers，页面未标明更新日期；核查日期：2026-10-13。
- GitHub·Document steps to take after emergency.recover · Issue #7023，页面发布或更新日期：2024-01-29；核查日期：2026-10-13。
