在 Lightning Network 中，通常由发送方构建路由。它结合公开 gossip 图、收款方提供的数据和自己的历史结果估计到达目的地的路径；从终点向起点反向计算每一跳的金额、费用和 CLTV，把指令封装进 onion packet，失败后再尝试其他路径。公开图不披露当前余额分布，因此 routing 是在不完整且快速变化的信息上进行的概率决策。
Routing 从 payer 开始：其 wallet 或 node 选择通往 payee 的候选 path，并为每个中间节点指定下一 channel。收款方提供身份、features，并可能提供 route hints 或 blinded paths；公开部分通常由发送方计算。
BOLT #7 传播 channel announcements 和定向 channel updates，其中包括 base fee、比例 fee、CLTV delta、最小值、最大值和可用标志。这些只描述公告的 policy 与拓扑，不能证明 peer 在线或通道当前有足够流动性。
公开 gossip 不显示通道两侧的 balance 分布。Router 会结合已知本地流动性、capacity、历史成功与失败、惩罚和实现自己的 scoring。理论上最便宜的路径未必成功概率最高。
金额和到期时间从 payee 向 payer 反向组装。每个转发 node 收到的金额必须覆盖下一 hop 加自己的 fee，incoming CLTV 还须按其 delta 高于 outgoing CLTV；更多 hops 会增加总费用与时间锁余量。
BOLT #4 使用 onion routing：payer 为每个 hop 创建带独立加密 payload 的 Sphinx packet。中间节点只知道相邻 peers 和自己的指令，不知道完整 path、长度或位置；流量分析与串通仍可能削弱隐私。
临时通道故障、fee 不足、CLTV 错误或未知 next peer 会向 payer 返回受限错误信号。实现可惩罚候选、重新计算并重试；一次结果不会永久描述通道，因为状态会变化。
每个 hop 都必须接受 HTLC，并在扣除储备、pending HTLC 及 htlc_minimum_msat、htlc_maximum_msat 限制后拥有正确方向的可用流动性。高总 capacity 或很多连接无法消除单个失衡通道的瓶颈。
若 invoice 支持 basic MPP，payer 可把 total_msat 分到多条 paths，由收款方作为一组结算。MPP 能使用分散流动性，但增加 HTLC、尝试和 fees，仍不会创造定向容量。
BOLT 11 route hints 可揭示末端未公告 hops；BOLT 12 与 route blinding 让收款方通过 introduction point 提供加密尾段。Payer 仍须找到通往首个已知点的路径并满足汇总 fee 与 CLTV 条件。
验证时记录实现及版本、amount、最大 fee 与 CLTV 限制、尝试次数、使用的 paths、完成时间和准确错误。应在相近时间比较同一对 nodes：成功属于具体付款和网络状态，而非永久全局分数。 资料来源: BOLT #4 — Onion Routing Protocol; BOLT #7 — P2P Node and Channel Discovery; BOLT #11 — Lightning Payment Encoding; Lightning Labs — Pathfinding; LDK — Routing and Route Parameters.
要获得更完整的理解，请将本词条与以下词条结合阅读： Lightning Network, HTLC, Lightning流动性, Payment Channel, Bitcoin, Inbound Liquidity. 反向关联还来自： HTLC, Lightning流动性, BOLT 12, Inbound Liquidity.