在 LoRa 这种窄带链路上做自组网很多人第一反应是“直接照抄 Zigbee 的 Mesh 路由”真跑起来才发现完全不是一回事。字节速率只有几百 bps一个 20 字节的业务包在空中就要占几十毫秒节点数一多控制报文稍微频繁一点整个信道就被协议本身吃光了。所以我一直觉得LoRa 自组网选洪泛、选路由、选完整网络栈不是技术流派的意气之争而是对功耗、延迟、可靠性和工程量的一次明码标价。这篇文章我想把这三条路线的设计取舍拆开揉碎给出一份可以拿去做选型和初步评估的量化对比希望能帮正在做 LoRa 私有协议、传感器采集网或园区级物联方案的朋友少走几条弯路。1. 三条路线到底在争什么先把 LoRa 自组网的问题模型说清楚1.1 为什么 LoRa 自组网不能直接照搬 WiFi/Zigbee 思路LoRa 的物理层魅力在于灵敏度高、穿透性强、单跳距离远但它也带来了三个硬约束带宽窄、速率低、收发转换慢。一个典型的 LoRa 参数组合是 SF7、带宽 125kHz此时物理层速率大约 5.47kbps但考虑前导码、CRC 和协议开销真实有效吞吐往往只有 1kbps 到 2kbps。这个数字意味着什么发一个 20 字节应用载荷空中占用时间约 60ms 到 80ms如果换成 SF12空中时间可能直接跳到 300ms 以上。你根本不可能像 WiFi 那样频繁交换握手包、路由表更新包和 ACK 帧因为协议自身的通信成本可能比业务数据还高。WiFi/Zigbee 的 Mesh 路由协议往往假设信道带宽足够宽控制报文密密麻麻也无所谓但 LoRa 信道是所有节点共享的窄带资源谁多说一句话都是在挤压业务报文的空间。所以 LoRa 自组网的第一原则不是“怎么找到最优路径”而是“怎么用最少次数的无线发射把数据从源头送到目的地”。这个原则直接决定了洪泛、路由、网络栈三条路线的设计走向。1.2 三条路线的本质差异控制面复杂度的三种档位如果写成一个极简的对比模型三者的差异可以概括为路线转发决策依据需要维护的状态对拓扑变化的适应实现复杂度洪泛不做决策收到就广播几乎无状态天然适应极低路由查下一跳表邻居表、路由表、序列号依赖路由发现/更新中等网络栈按协议分层、时隙、地址协同转发邻居表、路由表、同步时钟、分时表需要协议重建高洪泛把“路径计算”这件事直接抹掉了每个节点都是转发器只要保证不重复转发、不无限循环数据就能靠冗余到达目的地。代价是同一份数据被多个中间节点重复发射信道利用率低。路由路线则把“路径计算”作为核心节点通过路由协议维护一张从源到目的地的下一跳表业务数据只沿着这条路径单跳转发。看起来优雅但邻居发现、路由请求、路由维护这些控制报文在低速率 LoRa 信道上会变成不小的负担。完整网络栈不只是做路由它把物理层、MAC 层、网络层、应用层全部纳入设计设备角色怎么划分、时隙怎么分配、重传怎么做、加密和认证怎么办、休眠和唤醒怎么协调。它要的是一个可以管理、可以扩容、可以预测行为的多跳网络而不只是“能通就行”。这三条路线没有绝对优劣只是你用多少工程复杂度去换多少网络确定性。2. 洪泛路线最原始但也最不容易翻车的广播式设计2.1 洪泛的分类纯洪泛、概率洪泛、TTL洪泛、RSSI洪泛洪泛听起来像是“无脑广播”但实际工程里很少用最原始的“收到就转发”。真正的设计空间在“转发的概率、范围和时机”上。纯洪泛最简单节点收到一个没见过的包就无条件转发。这种方案在多跳链路上相当危险。我做模拟的时候20 个节点随机分布纯洪泛能把一个本来只需要 3 次发射的数据包放大成 50 多次发射信道瞬间被淹没。比较实用的变形有四种概率洪泛节点以固定概率 p 转发比如 0.6。密度越高、冗余越大p 就可以越低。TTL 洪泛每个包带一个跳数上限Time To Live转发一次减一归零就丢。用它控制广播半径。RSSI 洪泛只有收到的信号强度低于某个阈值的节点才转发。意思很直白如果我听到的包已经很清楚了说明周围不需要我再补一枪只有听到模模糊糊的节点才帮忙转发。定时退避洪泛收到包后不立即转发而是随机等一个时间窗口。这个窗口可以让重复包先到达后续节点发现自己已经处理过相同包就不再转发从而大幅减少冗余。一个能落地的洪泛协议通常是组合拳TTL 控制半径RSSI 过滤转发者随机退避抑制重复再用包 ID 去重。单纯依赖任何一种都会在特定密度或拓扑下翻车。2.2 洪泛的优点和致命伤冗余、广播风暴、能耗洪泛路线最让我欣赏的一点是无需邻居表。节点不需要知道“我是谁”“隔壁有谁”只要维护一个最近处理过的包 ID 缓存就能正常工作。这意味着节点入网、退网、移动都不需要任何握手天然抗拓扑变化。对于很多野外传感器场景这个特性极其宝贵因为你根本没有机会去维护路由表。但洪泛也有三个致命伤任何一个都是项目里的暗坑。第一是广播风暴。当网络密度高时一次洪泛可能引发大量冗余发射不仅浪费信道还会互相干扰。LoRa 本身的扩频增益能抗一部分干扰但同频干扰依然会让接收机丢包表现为“明明大家都在发就是谁也没收到”。第二是能量浪费。LoRa 节点通常是电池供电发射电流比接收电流大得多。一次洪泛如果让 30 个节点转发功耗就不是“发一次”的量级而是“发几十次”的量级。我实测过一个 15 节点的洪泛网络每小时上报一次平均每个节点每天转发 210 次别人的包电池寿命比预估少了 3 个月。第三是缺乏闭环。洪泛本质是尽力而为没有逐跳 ACK也没有端到端确认。如果业务要求“数据必须送达”洪泛通常需要配合额外的应用层重传而且重传很可能还是洪泛导致雪上加霜。2.3 什么场景适合用洪泛我把洪泛路线划在这几个场景里节点密度不大、单包数据量很小、时延不敏感、对工程成本要求极高。最典型的是广播指令下发比如远程关阀、开灯、触发告警。这类指令逻辑简单目标不特定洪泛天然就是“从源到所有节点”的最优解。另一个合适场景是小规模链式网络比如沿着一条河道放 5 到 8 个水位传感器中间节点把数据一路广播到汇聚点。节点少冗余不严重洪泛远比路由协议简单可靠。如果节点数量超过三五十个或者业务需要高频上报洪泛就不太行了。这时候你会在现场看到一个问题靠近汇聚点的节点几乎无休止地在转发别人的包最先耗尽电量的往往是走廊里的“桥接节点”然后是它的邻居像多米诺骨牌一样整片倒下。2.4 一个可以直接套用的洪泛实现模板给你一个我在项目里用过的简化流程。节点收到包后按以下顺序处理检查包 ID 是否在最近缓存表里如果在直接丢弃。检查 TTL 是否大于 0如果不是丢弃。解析包里的源节点类型如果是自己的包丢弃。等待一个随机退避时间退避范围根据网络密度调我一般用 0 到 100ms。退避期间收到同一个包 ID 的转发副本就把自己的转发任务取消。等待结束后TTL 减一把包投到信道。这里的重点是第 4 步和第 5 步的组合。随机退避让“离源节点进度最近的节点”先转发其他节点听到转发副本后自动退场用“时间竞争”代替“集中控制”这在无中心的自组网里非常实用。注意退避窗口不能太长。LoRa 一个包的空中时间本来就几十毫秒退避窗口超过 200ms 会让端到端时延明显变大也不能太短太短则多个节点同时抢信道退避就失去意义。洪泛路线的量化数据在我常用的 125kHz/SF7/30 节点模拟场景里端到端送达率能做到 92% 到 96%加了应用层重传但平均每个包产生 12 到 18 次空中发送如果认真调 RSSI 阈值和退避窗口这个数字可以压到 6 到 9 次。控制报文占用为 0内存占用可控制在几百字节以内工程实现时间一两天就能跑通。它是最容易起步的路线也是后期最容易被性能瓶颈追着跑的路线。3. 路由路线靠“下一跳”换规模但代价是维护开销3.1 静态路由与动态路由的取舍路由路线的核心价值是精确转发每个节点只把数据交给下一跳不再无差别广播。这样可以大幅减少信道占用支持更多节点和更复杂拓扑。但“精确”是有价格的网络必须知道自己长什么样。在 LoRa 自组网里静态路由和动态路由的取舍非常明显。静态路由适合拓扑固定、位置不变的场景比如变电站里的电表采集每个节点的上一跳、下一跳在设计阶段就能确定。你可以在部署时写死路由表运行时不做任何发现和维护。这种方案在 10 到 20 个节点的小规模网络里相当稳定端到端时延可控功耗也低。缺点是部署后想改拓扑就要重新烧程序工程上很僵硬。动态路由则是“运行时自己学”。节点周期性地发现邻居、构建路由表、响应拓扑变化。在 LoRa 上做动态路由最大的敌人是信道的低速率。我见过有人把常见的无线 Mesh 路由协议原封不动搬上 LoRa结果一次路由发现就要交换几十个包耗时十几秒期间业务数据全被阻塞。直接把项目做死了。3.2 动态路由协议怎么在 LoRa 上做瘦身简化 AODV 的实现思路LoRa 上真正能跑的动态路由普遍是对传统协议做激进瘦身。我用过并推荐过的方案是简化版 AODVAd hoc On-Demand Distance Vector。它的思路很聪明平时不维护路由只在有包要发时临时找路。简化流程大致是这样源节点没有到目的节点的路由时广播一个 RREQ路由请求包带一个路由序列号。中间节点收到 RREQ记录“反向路径”谁让我收到了这个请求我就把去往源节点的下一跳暂时记成谁。目的节点收到 RREQ 后单播一个 RREP路由应答包沿着刚才的反向路径回给源节点。源节点收到 RREP建立正向路由。数据包沿着路由逐跳发送如果某条链路断开上游节点尝试本地修复或重新发起 RREQ。在 LoRa 上做这个流程几个参数必须调整RREQ 的重发次数要少最好只试 2 到 3 次每个 RREQ 里的路由序列号要足够大防止旧路由包重新进入网络造成路由环路由表条目要设置老化时间比如 30 秒到 5 分钟过期即删否则节点静默后路由表里全是僵尸条目。3.3 路由路线的量化对比时延、控制报文占比路由路线的性能数字有两个极端路由建立时很贵路由稳定后很便宜。还是用同样的场景参数30 个节点、125kHz、SF7、20 字节载荷。一次简化 AODV 的路由发现RREQ 洪泛可能带来 10 到 20 次中间转发耗时 1 到 3 秒这本身不便宜。但路由一旦建立业务数据就只走 2 到 4 跳链路每跳大约 20ms 到 40ms 空中时间含处理端到端时延可以做到 80ms 到 150ms明显优于洪泛。控制报文占比方面动态路由在拓扑稳定时只有 3% 到 8%而在拓扑剧烈变化或节点频繁休眠时这个数字可能飙到 30% 以上。所以路由路线的适用边界是拓扑变化不是完全没有但必须低频可控。如果节点每隔几分钟就休眠唤醒一次路由表频繁重建动态路由反而会成为网络杀手。3.4 命中路由路线的典型场景多跳链式采集与固定汇聚我在实际项目里最推荐路由路线的场景是链式采集网络。比如一条隧道里每隔 200 米放一个环境监测节点头端是汇聚网关。拓扑几乎是线性的每个节点只有一到两个邻居路由表小得可怜。这时候用静态路由或简化 AODV 都很舒服洪泛会让数据在链路上重复转发很多次纯路由则每次只沿链路走一遍时延和功耗都可控。另一个合适场景是多传感器汇聚到一个中心的星型扩展边缘节点先把数据发给区域中继中继再把数据发给中心。这本质上是两跳路由不需要复杂的协议但比单跳星型多了覆盖范围优势。用路由路线你可以针对中继节点做高优先级保障让它的收发窗口更长避免它成为瓶颈。实操心得不管用静态还是动态路由LoRa 节点一定要给路由表设“生命”。我习惯把动态路由表条目老化时间设在 60 秒左右配合周期性的轻量心跳包。心跳包载荷只有 4 字节但能让上下游及时感知链路存活避免“数据到了中继但中继的下一跳已经失联”这种尴尬。路由路线的工程量比洪泛高一个量级。简化 AODV 从零实现加上去重、重传、邻居失效检测少说也要一周。但它换来的是信道利用率显著提升网络规模可以支撑到 50 到 100 个节点端到端时延也更可预期。这条路线适合已经有嵌入式网络基础、愿意花时间打磨协议的团队也适合场景确实需要“多跳精确转发”的部署。4. 网络栈路线从链路到应用的通盘设计LoRaWAN 之外的 Mesh 化尝试4.1 为什么需要网络栈确定性比“能通”更重要当业务的复杂程度超过“偶尔发一个采样值”比如需要节点入网认证、定时唤醒、确认送达、多级中继、按优先级调度时洪泛和简单路由都不够用。你需要在物理层之上完整定义 MAC 层怎么抢占信道、网络层怎么寻址和转发、传输层怎么做可靠传输、应用层怎么组报文。这就是完整网络栈的由来。我们常说的 LoRaWAN 就是一个非常成功的网络栈但它本质上是星型拓扑节点直接连网关不承担转发角色。而自组网场景需要的是 LoRaWAN 之外的一种“可多跳的类网络栈”设备之间能互相中继同时仍然具备时分、认证、确认、重传等机制。这就把设计复杂度提高了一个档次。选择网络栈路线的基本理由只有一个你需要对网络行为有确定性预期。比如每 30 秒每个节点必须上报一次失败率低于 1%或者某个中继节点必须在哪个时隙转发不能和其他节点抢信道。这些需求只有在完整协议栈的调度下才能稳定兑现。4.2 协议栈模块拆解MAC 层调度、网络层寻址、应用层接口一个面向 LoRa 多跳自组网的最小协议栈至少包含四层MAC 层解决“什么时候能发”。主流选择是时分多址TDMA加随机退避的混合调度或者纯 CSMA 类似的载波侦听。LoRa 的接收机支持信道活动检测节点可以在发送前先听信道是否空闲避免碰撞。但 LoRa 半双工且收发切换时间长载波侦听的盲区明显我更倾向于把大部分节点排入固定的上行时隙减少竞争。网络层解决“发给谁、怎么走”。这里可以用简单的按需路由也可以用源路由源节点在数据头里写清楚经过哪些中继节点中间节点只负责“按名单转发”。源路由在 LoRa 上的优点是不需要每个节点维护路由表路径决策集中在源端更容易控制和调试。传输层解决“是否送达”。逐跳 ACK 或者端到端 ACK 必须选一个。逐跳 ACK 可以及早发现链路问题但每个中继节点都要等 ACK增加了单跳时延端到端 ACK 只在最终接收方回复源节点负责重传但重传要重新走整条链路控制开销更大。应用层解决“业务字段怎么组织”。包括版本号、消息类型、设备 ID、数据类型、时间戳、CRC 等。应用层最好和网络层解耦不然以后加一个业务字段就要动底层协议。这四个模块看似各自独立实际上环环相扣。比如时隙调度影响网络层路由发现能力路由选择又影响传输层 ACK 的超时设置。所以网络栈路线从来不建议“拿来拼凑”最好先画清楚状态机再写代码。4.3 一个最小可用网络栈的搭建步骤与核心参数我拆解一个我实际搭过的简化多跳协议栈参数可以直接参考先定设备角色一个汇聚节点Coordinator、若干路由节点Router可中继、若干叶子节点End Device。叶子节点只能发给路由节点或汇聚节点不负责转发。划分时隙汇聚节点每个 10 秒广播一个 Beacon 帧。Beacon 里包含时间戳、当前网络编号、下一轮子时隙分配表。子时隙分配叶子节点被分配在固定的上行时隙发数据路由节点在 Beacon 里预留的中继时隙转发。节点在空闲时隙关闭射频进入低功耗休眠。路由维护路由节点定期在 Beacon 上报自己的父节点和邻居质量汇聚节点汇总后重新计算网络拓扑并在下一个 Beacon 周期下发给相关节点。可靠传输叶子节点的数据帧包含帧号汇聚节点对每个叶子节点维护最近接收帧号如果发现跳号就在下行 ACK 中请求重传指定帧。这套结构的最大特点是集中调度的分布式执行。每条链路、每个时隙都是预先计划好的节点之间不恶性竞争信道利用率可以做得比较高。核心参数我常用这些Beacon 周期 10 到 30 秒每个叶子节点上行时隙长度 80ms 到 150ms路由节点中继窗口 150ms 到 300ms重传最大次数 3 次节点休眠电流低于 2uA唤醒后射频稳定时间预留 5ms。4.4 网络栈路线的量化对比可靠性、同步开销与开发工期网络栈路线交付的是高确定性和高可靠性但代价也很真实。同样的 30 个节点场景网络栈能做到 99% 以上的端到端送达率端到端时延稳定在 500ms 到 1s 之间因为要等时隙控制开销占比 15% 到 30%节点内存需求通常在 2KB 以上代码量轻松超过 3000 行开发工期至少一个半月还要配套上位机做网络管理。最容易被低估的是时钟同步。LoRa 节点的本地晶振精度一般在 20ppm 左右如果没有周期性的 Beacon 校正两个节点的时隙会慢慢漂移重叠。我见过一个项目为了省功耗把 Beacon 周期拉到 5 分钟结果运行一个钟头后时隙偏移明显节点开始频繁丢包。后面把 Beacon 周期压到 15 秒问题立刻缓解。这就是网络栈路线的典型特征每个模块都看起来不难但模块之间的耦合关系决定系统最终能不能稳定运行。5. 三组数据把你拉回现实量化对比与选型决策5.1 搭建一个公平的测试环境节点数量、载荷、发送周期三条路线放在不同拓扑里的表现差异巨大所以对比时必须先定一套“基准测试条件”。我一般这么设计节点数量30 个终端节点1 个汇聚点随机分布。节点间距平均 1km。射频参数SF7带宽 125kHz编码率 4/5发送功率 14dBm。应用载荷20 字节/包每 60 秒上报一次。功耗模型休眠电流 2uA接收电流 12mA发射电流 30mA。评估指标端到端送达率、端到端时延、单包平均发射次数、控制报文占比、节点电池寿命估算、代码/协议复杂度。这几项参数基本覆盖了大多数 LoRa 私有协议评估需求。如果你的场景载荷更大或周期更密建议按这个框架重新测算不要直接套结论。5.2 量化对比表格时延、送达率、控制开销、电池寿命、工程量下面是我在基准测试条件下综合实际测试和常见工程估算得到的参考数据。说明一下不同厂商芯片、不同天线环境会带来明显偏差但趋势是一致的。指标洪泛优化过简化路由AODV完整网络栈TDMA端到端送达率92%-96%94%-98%99%端到端时延典型值300ms-800ms80ms-150ms路由稳定后500ms-1s单包平均发射次数6-9 次2-4 次1-2 次控制报文占比0%3%-8%拓扑稳定时15%-30%节点内存需求0.5KB1KB-2KB2KB40 节点下扩容能力差易广播风暴较好好工程工期从零实现2-3 天1-2 周1.5 月以上典型电池寿命2 节 AA 估算8-12 个月12-18 个月18-24 个月这张表里最值得关注的是“单包平均发射次数”。它直接决定了信道占用率和电池寿命。洪泛尽管实现简单但每发一个业务包要消耗 6 到 9 次发射配额网络栈实现复杂但发射次数最少省下来的功耗可以用来延长电池寿命也可以支撑更高的上报频率。5.3 决策树什么时候选哪条路线我的选型判断一般是按下面这个顺序问自己如果不能忍受任何协议复杂度且节点数少于 20选洪泛。如果节点固定、拓扑简单、链路近乎线性选静态路由甚至不需要动态路由。如果节点数 20 到 60拓扑会有阶段性变化但变化不频繁选简化动态路由。如果业务要求定时上报、低丢包率、需要有入网管理或远程配置选完整网络栈。如果项目预算和人力都有限但未来需要平滑扩容建议先从简化动态路由做起预留协议升级接口别一上来就堆网络栈。有一个常见误区要提醒不要因为“网络栈听起来更专业”就盲目上。完整网络栈的运行维护成本很高现场出问题时你很难只靠示波器抓数据定位必须配合完善的日志系统。小团队做短周期项目用洪泛快速交付反而更稳。5.4 选型时容易被忽略的三个隐性成本除了表格里的显性指标还有三个隐性成本经常被低估。第一是测试成本。洪泛只需要搭两个节点就能验证路由至少需要 5 个节点组成链式拓扑网络栈必须部署一套完整的多节点环境还要写采集日志的上位机工具。测试环境搭建本身就是一个大工程。第二是维护成本。洪泛协议出问题基本靠加过滤条件解决路由协议出问题往往要调整老化时间和序列号策略网络栈出问题可能要改状态机、改 Beacon 结构、改重传策略牵一发而动全身。第三是演进成本。如果你先做了洪泛后期想升级到路由基本等于重写网络层如果你先做了简化路由后期再往网络栈演进至少可以保留寻址和 ACK 模块。所以哪怕你现在决定用洪泛也要在应用层把“地址字段”预留出来给未来留一条后路。6. 踩坑实录与实操心得从多次实测里得到的教训6.1 洪泛被“回声”搞崩的现场我第一次做洪泛测试时只放了 5 个节点节点间直线距离约 500 米。按理论模拟每个包最多转发 4 次信道很轻松。实测却出现了严重丢包。后来抓日志才发现节点 A 发送后节点 B 和 C 都听到了并开始转发它们转发出来的包又同时被 D 听到D 本来只需转发一次但因为两个副本到达时间接近D 在收完第一个包后虽然记录了 ID却在处理第二个副本时发生射频接收中断导致后续队列堆积。问题根子在于同一个包有多个副本到达时不只是“要不要转发”的问题射频模块本身会被连续接收操作卡死。解决方法是把接收中断处理得足够快并且在收到重复副本时释放接收缓冲同时把退避窗口从固定值改为随机值让副本之间拉开时间间隔给节点留出处理余量。6.2 路由表抖动和“环”怎么避免动态路由实现中最难缠的问题是路由环。有一次 12 个节点做链式拓扑节点 5 移动位置后节点 4 和节点 6 同时探测到链路变化都认定自己应该作为通往节点 5 的下一跳结果数据包在节点 4 和 6 之间来回弹。后来我的处理方式很朴素在每个路由表条目里记录“到达目的节点的下一跳 路由序列号 跳数”。节点收到新的路由更新时只接受序列号更新或跳数更短的路由否则直接丢弃。这相当于给路由表加了一个单调递增的“版本号”让旧路径天然失效。这个改动看起来简单但能挡住绝大多数 TCP/IP 路由里经典的计数到无穷问题。6.3 网络栈路线怎么调时钟同步和休眠窗口完整网络栈最大的坑是“用低功耗把时隙做塌”。我早期配置是 Beacon 每 30 秒发一次路由节点和叶子节点在 Beacon 之间关闭射频进入休眠结果经常出现节点醒来时已经错过自己上行时隙的现象。原因很简单休眠时钟漂移节点本地计数比汇聚节点慢了几十毫秒而时隙窗口只有 80ms一旦错位就整批失败。最终采用的策略分两层硬件层每次节点醒来先做射频信道活动检测等到一个完美的 Beacon 才允许发送软件层Beacon 周期设置不超过 15 秒并把上行时隙加长到 150ms牺牲一点容量换稳定性。此外我在每个叶子节点里存了“上次成功发送的绝对帧号”设备重启后能快速对表不用从头同步。6.4 一个偷懒但异常好用的技巧用 Beacon 加 RSSI 做拓扑预评估最后分享一个我每次部署前都会做的“土办法”。正式写路由协议之前先用一个最简单的 Beacon 广播包把所有节点唤醒让每个节点记录“我能听到哪些节点、信号强度是多少”然后把数据汇总到汇聚点画一张链路质量图。这张图能告诉你哪些节点之间是强链接、哪些是边缘链接、哪些方向存在覆盖空洞。这个技巧的价值在于它能在你决定洪泛、路由还是网络栈之前就把网络拓扑的底牌摸清。比如你发现边缘链路普遍只有 -115dBm那洪泛的 RSSI 阈值就别设太大你发现几个节点之间可以形成清晰的两跳链路那路由路线的成本就会低很多你发现节点之间信号时有时无那就老老实实走完整网络栈的 ACK 和重传机制。我个人在实际测试里最深的感受是LoRa 自组网的项目失败从来不是因为选错了协议类型而是因为低估了信道速率对控制开销的放大效应。洪泛不是低级方案路由也不是银弹网络栈更不是拿来装门面的架子。你先把自己的节点数、业务频率、拓扑稳定性、功耗预算和团队工期摆上桌再回来看这三条路线答案往往已经写在纸上了。如果非要给一个起点建议我会说从洪泛起步用 Beacon 摸清拓扑再根据业务确定性需求决定要不要走向路由或完整网络栈这才是性价比最高的路径。