2.2 网络拓扑结构：星型、树型与网状
2.2 网络拓扑结构：星型、树型与网状
把设备放在空间上，用什么样的形状连接更稳？本节对比星型、树型、网状三种常见拓扑，拆解它们在可靠性、布线成本、拓展性上的取舍，帮你给项目选对连接形状。
这节读完你能定什么
阅读完本节，你应当能够：
- 画三种拓扑的示意图并指出各自的优缺点。
- 解释网状拓扑里"中继"对功耗的影响。
- 为智能家居、工业厂房、户外农田三种场景分别推荐合适的拓扑。
一、先看清问题：拓扑管什么
拓扑关心的是"空间上多个设备怎么连"。单个设备通信不涉及拓扑；项目里一上来十个八个节点甚至成千上万，它们彼此之间按什么形状走线路、走无线电跳，这就是拓扑要决定的。
现实里最常见的拓扑是三种：星型、树型、网状。三种的差异，最终都落到"一个节点掉线会不会牵连整个网络"与"要多付出多少布线成本或节点功耗"这两个天平两端。
二、三种拓扑，各有取舍
我们把三种拓扑放在一张对比表里，方便直观看差异：
星型是最简单：所有设备直接连中心节点（网关、路由器），不跟邻居聊。它成本低、没有额外的路由功耗，缺点太直白：中心一挂，全网停摆；一个节点越远，信号越难穿，距离受限。它适合几十米内设备不多、中心能稳定供电的场景——家里 Wi-Fi 就是天然星型，单个节点出问题不妨碍别人，除了网关换电一般没事。
树型是星型的层层嵌套：父节点带多个子节点，子节点再带更小的。它适合大规模厂区或园区分层采集，布线省钱、拓展灵活，但是父节点故障能带死一整片子孙，所以重要链路要做冗余。
网状是"大家互联互通"：每个节点可以当源、当目的地，也可以当中继帮邻居传报文。好处是天生自愈，一条路断了能绕另一条，哪怕几千个散落在农田里，总有一条路能到网关。代价是每个节点要醒着帮邻居转发，功耗直接上去，电池寿命会打折扣。Zigbee 在智能家居里常用网状就是因为这个特性——哪怕某个节点被水泥墙挡住了，信号能走邻居绕过去，不用拉网线。
三、实际组网里的杂糅
项目里不会纯用一种。比如城市路灯智能管理：每个路灯节点自己能当路由，路灯之间自组织网状，最后由几个骨干节点（网关）通过 NB-IoT 上云。这就是网状+星型的杂糅——内网 mesh 负责可靠，广域星型负责传上去，既保住了可靠性，又不浪费电池做无谓中继。
还有一个取舍：想省电就尽量少做中继，想可靠就多铺中继。平衡的办法很简单：把必须的骨干节点（网关）接市电，末端传感节点只传自己的，帮别人转发一次走一次休眠，功耗就能控在范围内。
三种拓扑在真实项目里怎么演
纸上画拓扑容易，落地全是取舍。给你三个能直接抄作业的案例。
智能家居（网状为主）：屋内墙体是最大敌人，信号的"直线距离"并不等于"可用距离"。这就是为什么智能家居爱用 Zigbee 网状——把各设备当成彼此的"跳板"，绕墙而行。但代价要记牢：每个参与转发的节点都要醒着为邻居出力，所以中继主力必须是常供电的插座、网关，纯电池门锁尽量只做末端，否则半年换一次电池谁也受不了。
楼宇自控（树型为骨）：一整栋楼几百上千个采集点，全做成星型会让网关喘不过气。业内常见做法是树型分层：地下机房做根，每层一个采集箱当"子父"，往下带那一层的温湿度、水表、电表，往上报给机房骨干。这种结构布线最省、扩展最顺，代价是"父"一旦断电，它名下整片子孙一起失联——所以关键父节点要双路供电、带冗余。
露天农业（网状 + 星型混合）：几百个土壤墒情节点散在几十亩田里，距离远、还没电。做法是网状把同批节点串起来，选几个位置居中的竖成"骨干"，骨干再通过 LPWAN 星型上云。多数节点只传自己的、偶尔帮邻居，真正的重活由骨干扛，电池就都不那么紧张。
把三个案例归一，选型其实就三句话：
节点少、中心稳 → 星型（最简单、最省） 规模大、要分层 → 树型（布线省、扩展顺，但父要冗余） 恶劣、要自愈 → 网状（拿中继功耗换可靠）
没有"哪种最好"的答案，只有"哪种和你的约束最配"。把三句话和三种拓扑各自的代价放在一起，现场就能快速拍板，不用再对着架构图发呆。
四、网状网络的功耗账：算清楚中继会吃掉多少电池
讲完了三种拓扑的骨架，网状拓扑里那个最容易被低估的账——中继对电池寿命的影响，值得单独拉出来算一笔。给一组真实数字你就明白：
一个 LoRa 传感节点不做中继，只上报自己数据，每天唤醒十次、每次十毫秒，平均电流可以压到 10 微安以内，一节 AA 干电池理论上能扛五年以上。如果它同时还要给邻居做中继，每天多转发三十个包，每个包平均耗电增加三倍，平均电流会跳到四十微安以上，电池寿命直接缩水到一年半。差四倍，就是"帮邻居转报文"这一件事造成的。
工程里怎么平衡？聪明的做法不是一律不让中继，也不是让所有节点都做中继，而是做骨干中继选点：把位置居中、市电可及（或大电池）的节点设定成骨干，只让骨干承担主要中继负载；末端纯电池节点只在闲时偶尔帮邻居转发一次，平时深度睡眠。这种"骨干网 + 叶子网"的混合网状，比全节点网状省电三到四倍，同时自愈能力并不丢多少。
实际选骨干有个简单 heuristics 算法：把整个网络的节点按位置画在网格上，每 2×2 个网格选一个离中心最近、电源条件最好的节点当骨干，每个骨干负责帮周围 3～5 个叶子节点中继。这么选出来的拓扑，功耗和可靠性刚好落在一个舒服的平衡点上。
五、星型拓扑并不纯：星型-簇状的变种藏在哪里
很多人以为星型就是"所有节点直连中心"，实际上物联网里最常见的星型其实是星型-簇状变种：先把物理位置接近的一组节点聚成一个簇，簇里选一个能力较强（电源足、算力好）的节点当簇头，簇头再星型连接中心网关。这种变种解决了什么问题？
它直接解决了"太远节点信号到不了网关"的老问题。比如一个地下停车场，深处的节点无线信号穿好几层墙到网关早就没了，要是先聚成簇让门口节点当簇头，簇头把这一片的数据汇聚完再一次性报给网关，信号就顺畅多了。同时，簇内节点可以低频唤醒簇头再转发，比每个节点都直接连网关更省电。
星型-簇状的代价也记一笔：簇头单点故障会带走整簇节点，所以簇头一定要选供电稳定的设备，关键区域可以留备选簇头——主簇头掉了，簇内自动投票选个新的顶上。这种"半分层"的星型，比纯星型灵活，比纯树型简单，是园区物联网里非常实用的隐形骨架。
六、一个真实故障排查案例：拓扑设计怎么坑了项目
说一个我见过的真实踩坑：某农业公司要在五十亩果园铺一百个土壤墒情节点，设计师怕麻烦直接全做成纯网状，每个节点默认都帮邻居中继。结果上线三个月，一批靠中心位置的节点电池就掉电过半，很多节点提前进入低功耗休眠，整片网络开始断连。排查下来发现：中心节点被周围七八个节点当成必经中继，每天转发几百个包，电流比设计值高了六倍，电池自然扛不住。
怎么改？方案很简单：只留每十亩一个、位置居中且接了太阳能板的节点当骨干中继，其他叶子节点只传自己的，只在骨干断了才临时顶一下。改完之后，平均电流下降 70%，电池寿命回到三年预期，断网问题自然消失。
这个案例告诉我们：拓扑设计不是"选个形状画在架构图上就完事"，你得蹲到现场算每个节点的功耗账——谁当转发、谁当叶子、电源够不够，这些细节比形状本身更能决定项目成败。
七、别忽略的第三条路：备份与异质接入
拓扑选完不等于完事。现实工程还常补两件小动作：给关键节点做备份路由，以及让网络"异构接入"。
先说备份路由。它和拓扑是两个维度的事：拓扑决定"默认怎么连"，备份决定"默认那条断了怎么办"。星型最容易因中心单点瘫掉，工程补救不外乎双网关、网关冗余电源、或给中心之外的末端留另一条 LPWAN/蜂窝回传。树型则重点给父节点做双路供电与备用父。换句话说，选拓扑时要顺手问一句"这条链上哪个点不能死"，把它单独列出来加固，比指望拓扑自己扛可靠更实在。
再说异构接入。一个真实园区几乎一定是"两种拓扑叠起来"：内网有条 mesh 把末端串成自愈网，出口又是一条星型把网关集中上云。这张"双层"结构不挑拓扑本身，而是把每种拓扑都用在最对的层。下判断时记住：拓扑解决的是"这层内部怎么连"，跨界可靠靠的是"层与层之间有备份"——别把两层都压成同一种连接，也别让单点毫无遮拦。
本节要点回顾
- 三种拓扑：星型简单，树型分层，网状自愈，取舍在可靠性与成本/功耗之间。
- 星型劣势：中心节点单点故障，越远越吃信号。
- 网状特点：多路径自愈，代价是每个节点都要帮转发，功耗上升。
- 选型口诀：小网走星型，大网分层走树型，恶劣环境可靠性要求高走网状。
- 典型搭配：内网网状 + 广域星型（网关做骨干），常见于城市级物联网项目。
讲完空间上怎么铺，接下来讲数据流的方向——下一节对比发布订阅与请求响应两种通信范式，看数据该走"推"还是走"拉"。