简介：这是一份围绕网络拓扑图绘制与编辑的源码包，面向网络运维人员、IT管理者以及需要定制拓扑绘图工具的开发者，可用于理解物理、逻辑与层次化拓扑结构，并支撑网络规划、故障排查、资源分配与安全监控等场景。压缩包共507个文件，约2.65MB，以285个svn-base版本文件、71个xml配置、60个png和23个gif图像资源为主，同时包含js、jsp、css、html、java、properties及数据库文件，整体呈现出较完整的Web图形编辑器项目结构。已有1086人学习或下载，能为拓扑可视化与源码改造提供参考。读者可从中了解绘图工具的页面组织、图形素材管理、前后端交互与配置方式，并在此基础上调整图标、连接关系或扩展设备发现、动态更新等功能，适合作为网络管理工具原型的学习样例。

1. 网络拓扑图到底是什么：把一团网线还原成一张能看懂的地图

家里网线越接越多之后，总会遇到一个棘手的问题：网突然断了，你蹲在电视柜后面，面对一团分不清哪根连哪根的水晶头和电源适配器，只能挨个拔插碰运气。网络拓扑图要做的，就是把这一团线还原成一张能看懂的图：哪台设备连着哪台、谁在上游、哪根线一断会带走一片工位，都清晰地画出来。它谈不上高深，本质就是一张“连接关系地图”：方块代表设备，连线代表链路，旁边标上地址和位置。搞懂它，你在排查断网、跟人描述网络、规划加设备这三件事上，都能少绕很多弯。理解了这张图，你就能更快定位故障、清楚表达网络结构，并在扩容前做好规划。

2. 为什么网络拓扑图非画不可：看不见的连接最容易出问题

2.1 断网那一刻，一张图就是你的应急参考

某公司办公区一半工位同时断网，值班的人只知道“网不好”，于是从出口设备开始，一层一层往下拔插网线，两个小时过去，问题还在。这类场景里最缺的不是技术，而是一张能告诉他“哪台设备在下游、哪台设备一挂就带走一片工位”的图。网络对大多数使用者来说是个黑匣子：插上网线就有网，中间经过了哪些设备、走了哪条链路，完全不可见。网络拓扑图就是把这个黑匣子拆开的第一层，它不解释协议细节，只回答一个最朴素的问题——谁连着谁。

有了这张图，故障现象就能直接对应到设备位置。断的是某台接入交换机的全部端口，问题大概率在这台设备本身或者它的上行链路；断的是零散几个工位，问题更可能落在终端、墙面面板或者一根跳线上。这跟城市供水管网是一个道理：知道总阀和分区阀在哪，漏水时能快速关掉一小片；不知道阀门位置，就只能整片区停水，靠一处处排查来碰运气。

图还能帮你估算故障范围。树型结构里，节点位置越靠上，影响面越大：出口设备一挂，全网断；核心交换机一挂，大半边断；某台接入交换机一挂，只影响它下面那十几个口。这个“影响面”不写在任何配置文件里，只在拓扑图上看得见。同理，动手前的风险评估也靠它：要重启一台设备，先看图上挂着多少下游；要拔一根线，先确认这根线是不是唯一通路。没有图，这些判断只能靠记忆，而记忆恰恰是运维现场最不可靠的东西。

提示：故障排查时先看现象范围，再回图上定位设备层级，比从出口设备一路往下逐台检查快得多。

2.2 一张图省下的沟通成本

口头描述网络最大的问题是空间指代会失效。“进门左手边那个柜子第二层那台黑盒子”，说的人觉得很清楚，听的人站在机柜前会发现有四个柜子、三台黑盒子，还都长得差不多。换成图上编号 A-03 的设备，指代就没有歧义，哪怕对方在另一个城市。

人员轮换时这个问题更明显。新接手的人拿到的往往是一堆能登录的设备地址和几张过期的配置备份，却不知道这些设备之间的从属关系：哪台是核心、哪台只负责一层楼、哪些口是留给备用线路的。靠逐台登录看邻居表去还原关系，一下午就过去了。一张标注清楚的拓扑图，能把这半天压缩成十分钟。

对外沟通也一样。线路服务方问“你这边网络是怎么接的”，写三百字不如发一张图；装修队问弱电箱到各房间怎么走线，图上标出点位比在现场比划有效得多。图的价值在于它是不同角色之间的共同语言：施工的人看位置，运维的人看链路，采购的人看设备数量，管理者看风险点，大家能在同一张图上指同一样东西，而不用先统一术语。

2.3 拓扑图上究竟该画什么：节点、链路、层级、标注

拓扑图不是设备清单的照片版，它画的是关系，所以第一件事是确定节点粒度。节点按角色画，不按品牌画：出口设备、边界防护设备、核心交换、接入交换、无线接入点、服务器、终端区域。把每一台终端都画成方块是最常见的过度绘制，十几个工位就能让图变成一团乱麻。正确的做法是聚合——用一个方块表示“三楼东区 24 个工位”，旁边标注所属网段。

链路要画清三件事：有没有线、多快、是不是备用。实线表示有线连接，虚线表示无线或者备份链路，主备关系用标注文字写清楚，别指望读者从线型猜。层级决定阅读顺序，常见的摆法是上游在上、下游在下，外网、边界、核心、汇聚、接入、终端自上而下排列，同一层的设备横向对齐。标注则是图的另一半信息量：设备名、管理地址、所在位置、关键端口号、所属网段。

图的信息密度要跟用途匹配。给动手的人看，端口号和网段必须写；给管理者看，区域和关键节点足够，塞满细节反而没人看。同一个网络画成两三张不同详细程度的图，比强行把所有人需要的信息塞进一张图更实用。

3. 常见网络拓扑结构：星型、总线、环型、网状到底差在哪

3.1 星型拓扑：家庭和小办公室的默认答案

星型拓扑是所有节点都连到同一个中心设备上。家里那台无线路由器就是中心：光猫接它，各房间的网口面板接它，电视、摄像头、手机也都连它。小办公室把路由器换成交换机，逻辑没变，仍然是所有设备围绕一个中心展开。

它的优点很直接。故障隔离好，一根线坏只影响那一个点，其余设备照常工作；扩容简单，加一台设备就是加一根线插到中心；排查路径短，任何一台设备出问题，先看它到中心这一段就够了。缺点同样直接：中心设备一挂，下面所有设备一起失联；中心端口数量决定规模上限，端口用完就得再加一台；中心设备的处理能力就是整个网络的上限，人一多就开始卡。

画星型图有个实用技巧：把中心放在中间或者顶部，其余节点呈辐射状排开，一眼就能看出“哪些设备共用同一个中心”。判断一张图是不是星型，数一下连接数就行：中心节点的连接数明显高于其他所有节点，其余节点的连接数基本都是一到二。这个特征在排查时很有用，因为它意味着任何一台终端的问题都大概率与中心设备无关，除非同时有多台终端出问题。

家用场景里还有一种变体：路由器下挂一台交换机，交换机再带一堆设备。这仍然是星型，只不过中心从一台变成了两台串联。画图时把两台都放在中间层，别把交换机画成终端，否则读图的人会误以为它跟电脑是同一级别。

3.2 总线型与环型：教科书里的老模型，现实里还有影子

总线型拓扑是一根主干线，所有节点都挂在上面。早期用同轴电缆的局域网就是这种形态，一根线串一栋楼，两端加终端电阻。它的好处是省线，缺点是主干一断全网瘫，节点一多冲突就严重，而且故障点极难定位——你得沿着那根线一段一段找。现在完整的总线型网络基本见不到了，但“一条主干带一串设备”的思路还留着影子，比如一根光纤串起多个接入点，主干断了后面全黑。

环型拓扑是节点首尾相连成一个圈，数据沿一个方向传递。它的特点是单点断线在双环结构下可以反向绕行，所以早期在一些对连续性要求高的场景里被采用。今天在工业控制网络和部分光纤环网里还能看到环形思路，但普通办公网络几乎不会用纯环型。

这两个模型真正值得记住的不是形态，而是它们揭示的区别：总线型是共享介质，所有节点抢同一根线；星型是点到点，每个节点有自己独占的一段。理解了这一点，你就能明白为什么网络从总线演进到星型——不是因为星型更漂亮，而是因为独占链路让故障隔离和带宽分配都变得简单。

还有一个容易犯的错：看到图上画了一个圈，就说是环型拓扑。很多冗余链路在图上确实会形成视觉上的环，比如两台核心交换机之间连了两根线，或者一台接入交换机同时上连两台汇聚交换机。这类环是冗余设计，逻辑上往往通过链路聚合或者生成树机制被处理成无环转发，跟“所有节点串成一个环”完全不是一回事。

3.3 网状与树型：数据中心和园区网的主力

树型拓扑，也叫层级型拓扑，是目前园区网的标准形态。它分三层：核心层负责高速转发，汇聚层负责策略和区域收敛，接入层负责连接终端。往上还有出口和边界设备。这种结构的优点是层次清晰、扩展方便、故障范围可控——某一层的某台设备出问题，影响被限制在它下面那一块。

树型的软肋在上层。核心层一挂，下面全断，所以真实网络里核心层通常要做冗余：两台核心互为主备或者负载分担，每台接入交换机同时上连两台汇聚设备。这些冗余关系必须画在图上，而且要标明是主备还是同时转发，否则读图的人会以为多出来的那条线是画错了。

网状拓扑是节点之间多路径互联。全互联的意思是任意两个节点之间都有直连链路，可靠性最高，但链路数量随节点数快速增长，三四台设备还能接受，十台设备的全互联就是四十多条链路，成本和复杂度都不可接受。所以真实网络里更常见的是部分互联：只在关键节点之间做多路径，其余保持单路径。

实际工程里最常见的组合是“树型打底、核心网状”。接入层老老实实做树型，保证结构清晰；核心层的两三台设备之间做全互联或者部分互联，保证关键路径不断。这样既控制了成本，又拿到了需要的可靠性。画图时把这两部分区分清楚，核心区的网状结构和接入区的树型结构用不同的布局密度表现，读图的人一眼能看出哪块是重点保护区域。

3.4 混合拓扑：真实网络的常态

真实的网络几乎不会只采用一种拓扑结构。一栋办公楼里，接入层是星型，每个楼层一台交换机带一片工位；楼层之间是树型，接入交换机上连汇聚；核心区可能是部分网状，两台核心设备之间有多条路径；无线接入点挂在接入交换机上，逻辑上补了一层覆盖；远端还有一个分支，通过专线连回来，画成一个云加一条线就够了。

无线接入点是个容易被画错的节点。它在拓扑上的角色是“接入层设备的下挂节点”，物理上通过网线连到接入交换机，同时还可能需要网线供电。画的时候应该放在接入交换机下面，跟终端区分开，标注覆盖区域，而不是混在一堆电脑中间。

还有一个常见现象是“图比网络复杂”。有些图为了显得专业，把每个终端的每个网口都画出来，结果主干结构被淹没。混合拓扑的画法原则是：主干结构必须清楚，边缘可以聚合。终端区域用一个方块加数量标注，比画二十个小方块有用得多。拓扑结构是一种描述工具，不是必须套用的规范，把真实关系画准，比套一个漂亮的标准形态重要。

4. 拓扑图家族里的易混区别：架构图、机柜图、布线图到底怎么分

4.1 网络拓扑图与网络架构图

这两者最容易被当成同一个东西，因为它们都是一堆方块加连线，名字里还都带“网络”。很多团队画一张图，既当现状记录，又当设计说明，结果两头都不太准。

混在一起的原因是绘图目的没有分开。拓扑图回答的是“现在连成什么样”，是一张现状快照，追求的是准确：这台设备在不在、这根线通不通、这个口接的是谁。架构图回答的是“应该怎么组织”，是一张设计蓝图，包含分层原则、区域划分、安全边界、冗余策略和地址规划原则，里面可以有还没上线的设备和还没实施的规划。

区分的方法有几个。看图上有没有“应该”“规划”“原则”这类描述性内容，有就是架构图；看图上有没有画出尚未上线的设备，有就是架构图；看改一根线要不要改图，要改的是拓扑图，架构图通常只在线路结构发生设计级变化时才动。再具体一点：架构图画“办公区与服务器区之间应当隔离”，拓扑图画“这两个区通过哪台设备的哪两个口相连”。前者说原则，后者说事实。

4.2 网络拓扑图与机柜图、布线图

这三张图经常被钉在机房同一面墙上，所以特别容易混。它们的区别在于看问题的角度不同。

拓扑图是关系视角，关心谁连谁，完全不关心设备装在第几个机柜、第几 U。机柜图是位置视角，画的是机柜的正视图或背视图，标注每台设备占几 U、装在第几 U、电源接在哪一路。布线图是路径视角，标的是端口号、配线架编号、线缆走向、长度和标签。

混在一起的原因是它们都跟物理设备和机房有关，而且经常由同一个人维护。实际使用时三张图是配合关系：拓扑图告诉你“问题出在这台设备”，机柜图告诉你“这台设备在 3 号柜第 12 到 14 U”，布线图告诉你“它上联的那根线在第 7 号配线架第 22 口”。只有拓扑图，你到了机房还得找；只有机柜图，你不知道这台设备挂了会影响谁。

判断一张图属于哪类很简单：图上有 U 位标注，是机柜图；图上有端口编号和线缆标签，是布线图；图上只有设备名和连接线，是拓扑图。三者可以画在一张纸上，但一定要分区，别让读者分不清哪部分是位置、哪部分是关系。

4.3 物理拓扑与逻辑拓扑

同一批设备，画出来的两张图可能完全不一样，这是初学者最困惑的地方。物理拓扑画的是线怎么走、口怎么接；逻辑拓扑画的是数据包怎么走、网段怎么划、路由怎么跳。

两者不一致是正常现象，原因有好几个。两台交换机之间用两根线互连做冗余，物理上是两条链路，逻辑上可能是一个聚合链路，看起来只有一条通路。一台交换机上划分了多个虚拟局域网，物理上是一台设备，逻辑上像是好几台互不相通的独立设备。几台设备分布在不同的物理位置，但配在同一个网段里，逻辑图上它们应该挨在一起画。

区分方法看标注：图上标的是端口号、线缆编号、设备位置，那是物理拓扑；图上标的是网段、地址、路由方向、安全域，那是逻辑拓扑。用途也不同：查“线是不是插错了”“这台设备到底连在哪个口”，用物理拓扑；查“为什么这个网段访问不到那个网段”“流量到底经过哪台设备”，用逻辑拓扑。

一个实用的经验是：排物理故障先看物理图，排访问不通先看逻辑图。两张图混着用，最容易出现的错误是拿着逻辑图去机房找线，或者拿着物理图去分析访问策略，方向从一开始就偏了。

4.4 拓扑图与流程图、思维导图

这三种图在绘图工具里的模板常常挨着放，都是节点加连线，所以经常被混用。但它们的连线含义完全不同。

拓扑图的连线表示连通关系，是“路”，通常没有方向，两个设备之间的链路是双向可通的。流程图的连线表示先后顺序，是“步骤”，必须带箭头，去掉箭头整张图就失去意义。思维导图的连线表示从属与分类，是“包含”，一个父节点展开多个子节点，表达的是归属关系而不是物理连接。

混用带来的后果很实际。有人在拓扑图上加箭头表示“数据流向”，结果读者以为那是单向链路；有人在流程图里画了双向箭头，导致步骤顺序变得含糊。判断方法很简单：把图上所有箭头去掉，如果意思基本不变，那它更接近拓扑图；如果去掉箭头就看不懂了，那是流程图。再补一条：图上出现“第一步、第二步”这样的文字，它就不是拓扑图。

5. 一张网络拓扑图怎么画出来：从确定视角到连线规范

5.1 先定视角：这张图给谁看

动手画之前先问一句：这张图给谁看。答案不同，画法差别很大。

给动手的人看，比如运维和施工，图要带管理地址、端口号、网段、设备位置，越具体越好，因为他们要照着图去插线、去登录、去排查。给做决策的人看，比如管理者和采购，只需要区域划分、出口链路、关键设备和冗余情况，细节太多反而看不清重点。给复盘的人看，比如故障分析，图必须带时间点和变更记录，画的是“故障发生那一刻的状态”，而不是现在的状态。

一张图同时满足三类读者是很难的，所以宁可按读者分成两三张。常见做法是：一张全局概览图给所有人看结构，一张详细连接图给运维用，一张区域图给施工用。三张图共用同一套命名和布局习惯，对照起来不会错位。

还要记住一点：图本身不会自动解释自己。设备名用了缩写，就要有图例；线型有特殊含义，就要有说明；区域有划分，就要标注边界。一张没有图例的拓扑图，对不熟悉这个网络的人来说，信息量会减少很多。

5.2 分层与分组：核心、汇聚、接入怎么摆

布局的第一原则是纵向分层。从外到内依次是外部网络、边界设备、核心设备、汇聚设备、接入设备、终端区域。上游在上，下游在下，同一层的设备横向对齐。这样读者视线从上往下扫，就能顺着数据流向理解结构。

第二原则是横向分组。按楼层分、按部门分、按安全域分，都可以，关键是全图统一。三楼一个区、二楼一个区，区域之间留出明显的间隔，别让两个区域的线缠在一起。分组之后，每个区域角上标一个网段或者区域名，比在每台设备旁边标地址清爽得多。

第三是命名规范。推荐“位置-角色-序号”的格式，比如“3F-ACC-01”表示三楼第一台接入交换机。好处有三个：图上一眼知道设备在哪，排序整齐不会乱，口头沟通时不会产生歧义。命名规范一旦定下来就要严格执行，最怕的是同一张图上出现三种命名风格，读图的人得先在脑子里做一次翻译。

第四是图例。线型、颜色、图形分别代表什么，放在图的角落。图例不需要复杂，五六条足够，多了说明图本身设计得太花。

5.3 图元与连线规则：线型、颜色怎么用

线型是最基础的编码。实线表示有线连接，虚线表示无线或者备份链路，双线表示冗余或者聚合。这套约定不需要自创，用大家熟悉的就行，自创规则只会增加沟通成本。

线宽可以表示带宽级别。主干链路画粗一点，接入链路画细一点，读者不用看标注就能感觉到哪条是主要通道。但线宽最多分三级，分太多就看不出差别了。

颜色要克制。颜色适合表示区域或者安全域，比如办公区一种色、服务器区一种色、外部网络一种色，四到五种就够了。有两点要注意：颜色必须配文字标签，因为不是所有人都能分辨颜色；不要用颜色表示“重要”“不重要”这种主观属性，重要程度应该靠位置和线宽体现，颜色表达不了程度。

最难处理的是连线交叉。一条线穿过三个设备，读者会以为它们之间有连接。处理办法是调整设备位置减少交叉，实在避不开就用跳线符号，或者把图拆成两张。宁可多画一张图，也不要把一张图画成蜘蛛网。

还有一个容易被忽略的规矩：同一批设备在不同图里的相对位置尽量保持一致。全局图里核心在中间，区域图里核心也应该在中间或者顶部，不要让读者每换一张图就重新建立一次空间记忆。

5.4 用代码描述拓扑：邻接表与结构识别

拓扑图的本质是一份连接关系数据，图只是它的一种呈现方式。设备数量少的时候，用手拖方块没问题；设备一多、变更一频繁，手画的图很快就会跟现实对不上。这时候更靠谱的做法是先把连接关系维护成结构化数据，再考虑怎么渲染。

下面这段 Python 用字典存了一张小型办公网的邻接关系，然后找出哪些设备一旦失效会让其他设备失联。

# 邻接表描述一张小型办公网络 # 键是设备名，值是与它直连的设备列表，两个方向都要写全 topology = { "internet": ["router"], "router": ["internet", "firewall"], "firewall": ["router", "core-sw"], "core-sw": ["firewall", "acc-3f", "acc-2f", "server-sw"], "acc-3f": ["core-sw", "pc-3f-01", "pc-3f-02", "ap-3f"], "acc-2f": ["core-sw", "pc-2f-01"], "server-sw": ["core-sw", "db-01", "app-01"], "ap-3f": ["acc-3f"], "pc-3f-01": ["acc-3f"], "pc-3f-02": ["acc-3f"], "pc-2f-01": ["acc-2f"], "db-01": ["server-sw"], "app-01": ["server-sw"], } def is_connected(graph, removed=None): """摘掉 removed 节点后，剩余节点是否还连在一起""" nodes = [n for n in graph if n != removed] if not nodes: return True start = nodes[0] seen = {start} stack = [start] while stack: cur = stack.pop() for nxt in graph.get(cur, []): if nxt == removed or nxt in seen: continue seen.add(nxt) stack.append(nxt) # 剩余节点全部被访问到，说明图仍然连通 return seen >= set(nodes) def find_spof(graph): """逐个摘掉节点，返回摘掉后会让网络断开的节点""" result = [] for node in graph: if not is_connected(graph, removed=node): result.append(node) return result print(find_spof(topology)) # 输出：['router', 'firewall', 'core-sw', 'server-sw', 'acc-3f', 'acc-2f']

这段代码的逻辑很朴素：把每个节点依次从图里摘掉，看看剩下的节点还能不能从一个点走遍全部。走不通，说明这个节点一旦挂掉，就会有其他设备跟着失联。

参数说明：topology是邻接表，键为设备名，值为直连设备列表，必须双向写全，只写一边会导致遍历时漏掉方向；removed控制摘掉哪个节点，传None表示不摘；is_connected用栈做深度优先遍历，只判断连通性，不关心路径长短。

输出结果里出现的都是“有下游”的设备，叶子节点被摘掉不会影响别人，所以不在结果中。这也说明一件事：结构分析只能告诉你“谁挂了会带走别人”，带走的这些设备重不重要，还得靠人判断。某台打印机断了不算事故，服务器区那台交换断了就是大事。图给结构，优先级由人来定。

这段代码真正的价值不在算法，而在提醒一件事：拓扑图应该从数据生成，而不是靠手拖。设备超过二三十台之后，手工维护的图几乎必然会跟现实脱节，而结构化的邻接表可以进版本管理、可以做差异对比、可以在变更时先改数据再出图。

5.5 工具怎么选：手绘、在线图、代码生成

工具没有优劣，只有匹配。白板手绘适合快速沟通，讨论的时候随手画两笔，比打开软件快得多，缺点是画完就没了，不适合留档。在线绘图工具模板多、协作方便，适合团队共同维护一张图，缺点是图跟真实配置容易脱节，改完设备忘了改图是常态。

文本描述生成图的方式适合变更频繁、设备较多的环境。图由文本定义，文本能进版本管理，每次改动都能看出差异，出问题时还能回到上一版对比。代价是需要先学一套描述语法，前期投入比拖方块高。

监控或者管理平台自动发现的拓扑准确度最高，因为它直接读取设备的邻居关系表。但它给出的往往是一堆原始连接，没有分层、没有命名、没有区域划分，需要人工整理一遍才能看。常见做法是自动发现打底、人工整理成图，既保证准确，又保住可读性。

选型可以按规模粗略判断：设备十台以内，手画或者在线工具足够；几十台并且有专人维护，在线工具配合定期核对；上百台且变更频繁，值得投入结构化描述或者自动发现。关键不是用哪个工具，而是有没有人负责让图跟现实保持一致。

6. 什么时候该画、什么时候别画：一张图的成本与边界

拓扑图不是画得越多越好，它也有成本：画要时间，维护要人，过期的图比没有图更糟。一张三年前的图，会让人做出错误判断——按图去机房找一台早就换掉的设备，或者以为某条链路还在，结果那天恰好是唯一通路。

判断标准可以简化成一句：这张图三个月后还有人看吗。有人看，就必须有维护人，否则别画。下面这张清单覆盖了常见场景。

有几条经验来自实际遇到的问题。第一，接手一个新环境，先画图再改配置。不画图就动手，很容易在不知道下游有多少设备的情况下重启一台核心设备，然后整个办公区的人一起等你。第二，图画完要跟现实核对一遍，别照着旧文档抄，设备可能早就换过位置。第三，图上要有日期，这比任何注释都重要，看到日期就知道该不该信它。

也有明确不该画的时候。单机环境、临时实验、只存在几天的测试网络，画精细的拓扑图纯属浪费。真正需要警惕的不是“没画”，而是“画了不管”：一张没有维护人的图，会在半年内变成误导信息，还不如墙上贴一张设备清单。

从那以后我每次接手一个新环境，第一件事不是登录设备改配置，而是先把现有连接摸一遍、画成一张带日期的图，哪怕只是手绘拍照。这个习惯让我少踩了好几次坑，也省下过整晚的排查时间。希望帮到你。

本文还有配套的精品资源，点击获取