手绘LwIP协议栈思维导图：嵌入式TCP/IP代码结构入门指南

拿一份LwIP源码直接开读，十个新手有九个会被tcp.c里那一万多行代码劝退。我当年第一次接触LwIP协议栈，点开src目录的瞬间就懵了——tcp_in.c、tcp_out.c、api_msg.c、pbuf.c、memp.c，每个文件看起来都和代码结构有关，但没人告诉我应该先从哪个文件入手，更没人告诉我这些文件之间到底是怎么协作的。

后来我花了两周时间，把LwIP源码按功能归类、按调用关系连线，手工画了一份完整的LwIP协议栈代码结构思维导图。这张图一下子把整个协议栈的骨架和血肉都串了起来：内存管理在哪、网络接口在哪、TCP状态机在哪、socket API是在哪一层封装的，全都一目了然。之后再回去读tcp_in.c，完全不是原来那种走迷宫的感觉，而是像拿着一份城市地图在找路。

这篇文章就把我当时画图的整个过程、模块划分的逻辑、每个核心文件的职责边界，以及读码顺序完整复现出来。内容适合正在学嵌入式网络、第一次接触TCP/IP协议栈、或者要在实际产品里裁剪和二次修改LwIP源码头文件的人。不管你是拿LwIP做简单的以太网设备、做lwip双网口网关，还是在STM32上配合YT8512C这类PHY芯片做联网功能，先把代码结构摸清，后面调试、裁剪、移植都会省非常多的事。

1. 为什么要靠思维导图啃LwIP代码

1.1 LwIP到底是个什么级别的协议栈

LwIP全称Lightweight IP，是开源的轻量级TCP/IP协议栈，最初由瑞典计算机科学研究院发起，后来由社区持续维护。它和Linux内核自带的TCP/IP协议栈最大的区别就是“轻”和“可裁剪”。Linux的协议栈代码量大、深度依赖内核的各种机制，适合跑在带MMU、内存以GB计算的操作系统上；而LwIP的目标是几十KB到几百KB内存的MCU，纯C语言实现，不强制依赖操作系统，既能跑在裸机上，也能跑在FreeRTOS这类RTOS上。

但“轻量”并不意味着“简化到业余”。LwIP完整实现了TCP协议的核心机制：三次握手、四次挥手、滑动窗口、超时重传、慢启动、快速重传与快速恢复、糊涂窗口综合症避免等都在。它还把零拷贝、DMA描述符这类嵌入式常用的内存优化技巧做进了pbuf体系里。正因为实现密集，它的代码结构是典型的“浓缩型”布局——一个tcp.c里就塞进了连接管理、状态转换、定时器处理等大量逻辑。文件少、单文件函数长，这种结构如果不先画一张图理清层次，直接啃源码非常容易陷入细节出不来。

1.2 思维导图解决的是“记不住、理不清”的问题

嵌入式工程师读协议栈和读普通业务代码的体验完全不一样。普通业务代码你可以从上到下顺着读，但协议栈是多事件驱动、多回调嵌套的。在LwIP里，一个数据包的完整旅程要经过网卡驱动、netif层、IP层、TCP层，最后才到应用回调，每一层之间的交接靠的就是函数指针，代码散落在好几个文件里。没有地图的情况下，很容易出现这种状态：跟着tcp_recv回调去找它是谁调用的，跳了七八个函数，回来时已经忘了最初要看什么。

思维导图在这里的作用就是外置大脑。它把“函数之间的静态调用关系”和“数据包的动态流转路径”统一表达出来。树的分支是模块归属，箭头连线是数据流向。你读代码之前先看图，明确“我现在在树的哪根枝上、数据要从哪里来、要到哪里去”，再回去看具体实现，效率完全不一样。

注意：这里说的思维导图不是UML类图，不用把每个函数都塞进去。粒度应该控制在“模块—文件—关键结构体—核心API—数据流方向”这个层级，再细的细节留给代码本身。图如果画到函数级，信息量太大，反而起不到导航作用。

2. LwIP的目录与模块体系：先把骨架立起来

2.1 顶层六大模块划分

从源码目录看，LwIP（以2.x版本为例）可以划分成六大模块，这也是我画思维导图时的第一层树枝：核心协议模块（src/core）、API模块（src/api）、网络接口模块（src/netif）、应用模块（src/apps）、头文件与配置模块（src/include）、系统适配模块（移植层的sys_arch）。

每个模块在源码里都有真实目录对应，不是凭空分的。核心协议模块是协议栈本体，包含IP、TCP、UDP、ICMP、IGMP、DHCP、DNS等协议的实现文件；API模块是给应用层调用的编程接口，包括socket API和netconn API；网络接口模块负责把各种物理链路接入协议栈，比如以太网、SLIP串口线路、PPP拨号；应用模块是官方附带的现成应用，比如HTTPd、MQTT、SNMP、TFTP；系统适配模块是你在移植时必须自己写的部分，封装了信号量、互斥锁、邮箱队列、超时等操作系统原语。

在XMind里画的时候，根节点写“LwIP代码结构”，第一层就是这六个分支，每个分支后面标注对应的目录路径。这样这张图天然就成了一个源码导航，想看哪个模块，顺着分支就能定位到具体目录和文件。

2.2 每个目录里都有什么：对应思维导图的第一层树枝

核心协议模块是画图的重头戏。src/core下面还分成ipv4、ipv6两个子目录。ipv4目录负责IPv4路径上的协议处理，核心文件有ip4.c、etharp.c（以太网ARP）、icmp.c、igmp.c、autoip.c；ipv6目录对应的是ip6.c、icmp6.c、mld6.c、ethip6.c等。如果你的产品只做以太网IPv4，IPv6那整整一枝可以先折叠起来，等需要时再展开，这本身就是LwIP可裁剪性的体现。

src/core根目录下的文件更要逐个搞清楚职责。tcp.c负责TCP控制块管理和状态机入口，tcp_in.c负责接收报文处理，tcp_out.c负责发送报文构造；udp.c负责UDP控制块和收发逻辑；raw.c提供裸IP收发能力；mem.c是堆内存管理器，memp.c是固定大小内存池，pbuf.c是数据包缓冲抽象层；netif.c是所有网络接口对象的管理中心；timeouts.c是协议栈的超时定时器；sys.c是平台无关的系统调用抽象。这些文件在思维导图里单独列一个“core核心”二级分支，每个文件再展开成“职责—关键结构体—关键API”三级节点。

src/api目录和src/core一定要分开画。sockets.c实现了BSD风格socket；api_lib.c和api_msg.c实现netconn编程模型；netbuf.c是netconn的数据缓冲封装；netifapi.c用于在线程安全环境下操作netif。如果你的产品走raw API那条路（无操作系统或者不想用socket），那整棵api层的分支都可以在思维导图里折叠掉，因为它本质上是协议栈的可选外挂，并不参与核心收发包逻辑。

src/netif目录下，ethernet.c负责把netif对象和以太网驱动对接，输出标准的eth_input、eth_output入口；slipif是串行线路接口；ppp目录里是一整套点对点协议族，包括PPPoE、PPPoL2TP等。对大多数以太网设备来说，你真正关心的只有ethernet.c和你自己在板级BSP里写的网卡驱动。注意，网卡驱动文件通常不在LwIP源码里，而是在你工程目录下的驱动文件夹，比如STM32平台的stm32_eth.c。这条边界一定要在思维导图上标清楚：哪些是官方源码，哪些是用户移植代码，后续裁剪和换芯片时才不会改错文件。

2.3 lwipopts.h：藏在配置里的隐性模块

很多人画LwIP思维导图会漏掉一个关键节点——lwipopts.h配置文件。它虽然不在src目录下，却决定了整个协议栈编译出来有多大、哪些功能开哪些关。LwIP靠编译宏来裁剪功能，比如LWIP_TCP决定要不要编译TCP，LWIP_UDP决定要不要编译UDP，NO_SYS决定是否基于操作系统运行，MEM_LIBC_MALLOC决定堆内存是走C库malloc还是走LwIP自带管理，TCP_MSS决定最大报文段长度，PBUF_POOL_SIZE决定pbuf内存池的数量。

我在思维导图里专门加了一个“配置开关”分支，把lwipopts.h里的宏按功能归类，挂到对应模块旁边。内存模块下挂MEMP_NUM_*、MEM_SIZE；TCP模块下挂TCP_MSS、TCP_WND、TCP_SND_BUF；网络接口模块下挂LWIP_NETIF_REMOVE、LWIP_NETIF_LOOPBACK。这么做的好处是，调试“为什么某个功能没生效”时，先顺着图排查配置分支，而不是一头扎进源码里考古。

3. 核心代码结构详解：思维导图的主干怎么画

3.1 内存三件套：pbuf、mem、memp

LwIP最值得先画清楚的是内存管理体系，它由三个文件配合完成：pbuf.c、mem.c、memp.c。很多新手把这几个搞混，其实分工非常明确。pbuf是统一的数据包缓冲抽象，本身不直接管“内存从哪来”，而是管“缓冲区怎么组织、怎么用”。以太网帧在收包、转发、向上递交的过程中会被不同协议层反复引用和拼接，pbuf用链式结构解决了头部预留、引用计数、数据拼接这些高频操作，对外提供pbuf_alloc、pbuf_free、pbuf_cat、pbuf_header等接口。

mem.c是堆内存分配器，使用首次适配算法，为小内存嵌入式设备专门优化，支持对齐、支持内存使用统计。所有PBUF_RAM类型的pbuf、TCP段发送缓冲等，都是从这块堆里申请的。memp.c则是固定大小内存池，按用途预分配若干固定槽位，比如TCP控制块池、UDP控制块池、PBUF_POOL池、ARP缓存池、netconn池等，每个池的数量由MEMP_NUM_*宏控制。

这三个文件在思维导图上的关系，我建议画成“嵌套”而不是“并列”：最外层是pbuf抽象，向外提供数据包接口；pbuf底层有两种内存来源，PBUF_POOL类型的数据区来自memp固定池，PBUF_RAM类型的数据区来自mem堆。理解了这层关系，也就明白了为什么LwIP要提供两种pbuf类型：池方式分配速度极快、不会产生堆碎片，适合在中断上下文里收包；堆方式分配灵活、能动态调整大小，适合应用层不固定的大块数据。

实操心得：STM32配合LwIP跑一段时间后，如果报“pbuf_alloc failed”或者某类内存池耗尽，优先查MEMP_NUM_PBUF和MEM_SIZE的配置，以及代码里是不是有pbuf申请了没释放。把MEM_STATS、PBUF_STATS这类统计宏打开，在串口日志里能看到每个池的当前使用数和历史最大值，定位内存泄漏比瞎猜快得多。

3.2 netif网络接口层：双网口与YT8512C的落点

struct netif是整个网络接口层的核心抽象，它把“一块网卡”变成协议栈可以管理和调度的对象。每个物理网口对应一个struct netif实例，LwIP通过一个单向链表把所有netif串起来，netif_add负责注册，netif_set_up设置启用状态，netif_set_default指定默认出口。如果你的设备做了lwip双网口，比如一个网口接内网、一个接外网，那就是注册两个netif实例，分别绑定不同的MAC和PHY，再用路由选择逻辑实现流量分流。

这里顺带说下热词里的YT8512C。这是一个10/100M自适应以太网PHY芯片，常见于国产化方案和STM32平台的以太网板卡上。它的驱动代码不在LwIP里，而是在你的板级驱动中，负责通过MDIO读写PHY内部寄存器，完成自协商、link状态检测、LED控制等工作。从代码结构图上看，它属于netif分支下的“物理层驱动”叶子节点，位于协议栈最底层。LwIP的netif层通过ethernetif_init这类回调函数和PHY驱动对接，数据从PHY到MAC、再通过DMA进入内存描述符，最后由netif->input函数把包喂给协议栈。

我特别建议在思维导图上把“网卡驱动到底属于谁”这条边界画清楚：LwIP官方代码不包含具体PHY芯片驱动，它只定义netif接口规范；具体PHY并入你自己的网卡驱动实现。这样当你要把PHY从YT8512C换成别的型号时，只需要重写驱动叶子节点，协议栈主干完全不用动。这就是模块化设计的价值，也是一张代码结构图最想传达的东西。

3.3 TCP协议栈核心：tcp.c、tcp_in.c、tcp_out.c怎么分

TCP是LwIP里最复杂的枝干，思维导图必须拆细。官方按职责把TCP代码分成三个文件，对应三种视角：tcp.c管“连接生命周期”，tcp_in.c管“收到的报文怎么处理”，tcp_out.c管“发出的报文怎么构造”。三者的协作全部围绕struct tcp_pcb展开。tcp_pcb就是TCP协议控制块，记录了源端口、目的端口、发送序号、确认序号、接收窗口、重传定时器、拥塞窗口等一整套连接状态。

tcp.c里的关键函数包括tcp_new、tcp_bind、tcp_connect、tcp_listen、tcp_accept、tcp_close、tcp_abort，这些是应用层主动调用的入口，也是连接状态发生迁移的触发点。tcp_in.c最核心的是tcp_input，它由IP层在收到TCP报文时调用，内部根据报文五元组在PCB链表中查找对应控制块，随后进入tcp_process状态机处理，最后调用tcp_receive完成数据接收和确认应答。tcp_out.c则集中了tcp_enqueue_flags、tcp_write、tcp_output、tcp_rexmit等函数，负责把应用数据切分到合适的MSS大小、构造TCP报文头、计算校验和、推入发送队列，并在收到ACK后管理重传。

在思维导图里，我把TCP枝画成三层。第一层“PCB管理”，挂tcp.c和tcp_pcb结构体；第二层“报文处理”，分tcp_in.c和tcp_out.c两个子枝；第三层“状态机”，列出CLOSED、LISTEN、SYN_SENT、SYN_RCVD、ESTABLISHED、FIN_WAIT_1、FIN_WAIT_2、CLOSE_WAIT、CLOSING、LAST_ACK、TIME_WAIT这11个状态，每个状态旁边标注触发迁移的事件，比如收到SYN、发出FIN、收到ACK。画完这一枝，TCP在你脑中的结构就是一棵可以随时展开的状态树，而不是满屏的if-else嵌套。

3.4 UDP与IP：相对轻量的两个分支

UDP分支好画得多，核心只有一个udp.c。struct udp_pcb是UDP控制块，核心API是udp_new、udp_bind、udp_connect、udp_sendto、udp_recv。它也有回调机制，udp_recv_fn_t回调会在收到匹配报文时被协议栈调用。如果你的产品主要用UDP做组播、广播或者轻量数据上报，这一枝在思维导图里可以简化为“控制块管理”和“收发处理”两片叶子，不用展开太多。

IP层在思维导图里要注意区分IPv4和IPv6两个子枝。IPv4对应ip4.c里的ip4_input、ip4_output、ip4_route，配合etharp.c做ARP地址解析；IPv6对应ip6.c、icmp6.c、mld6.c。ip_input在剥掉二层以太网头之后，根据报文版本号把包分发给ip4_input或ip6_input，然后查路由，决定是上抛给本地协议栈还是转发出去。ICMP就是平时ping用的那个协议，实现在icmp.c里；IGMP组播协议在igmp.c里。这两个一般作为IP枝下的叶子节点，除非你在做组播相关产品，否则不用深入。

4. API层与应用层：两条使用路径的代码脉络

4.1 raw API与sequential API：两种完全不同的开发模式

LwIP给应用层提供两套接口，思维导图里一定要分开画，因为它们的代码路径完全不同，遇到问题时的排查思路也不同。raw API也叫回调API，你把回调函数直接注册给协议栈，数据包到达时，协议栈在处理上下文中直接调用你的函数。这种方式不依赖操作系统线程，性能高、代码省，但写起来要处处小心，不能在里面做耗时操作，也不能随便阻塞。常用函数有tcp_recv、tcp_accept、tcp_sent、tcp_poll、tcp_err，本质就是给TCP控制块挂一组函数指针。

sequential API是面向操作系统的。sockets.c是BSD socket接口在LwIP里的移植实现，App线程里调用的socket、bind、listen、accept、send、recv，最终会通过netconn层打包成消息，投递到tcpip_thread线程；tcpip_thread再调用底层的raw API完成真正收发。如果你用的是FreeRTOS这类RTOS，最省事的方案就是建一个tcpip_thread跑协议栈线程，业务线程里用socket API写收发，代码可移植性高，调试起来也更像平时写Linux网络程序。

在思维导图上，我会在应用层的位置画一个分叉：左侧接入点选“raw API”，后续连线直接连到tcp/udp核心；右侧接入点选“socket API”，必须先经过sockets.c、api_msg.c、消息队列、tcpip_thread，最后才到协议核心。数据在这两条路径上停留的节点完全不同，你调不通时排查方向自然也完全不同。

4.2 socket层与netconn层的调用关系

sockets.c是表皮，netconn才是里子。每个socket内部都对应一个netconn结构体，每个netconn内部又对应一个或多个协议控制块。比如你调用socket(AF_INET, SOCK_STREAM, 0)创建一个TCP套接字，它会走到netconn_new(NETCONN_TCP)，然后netconn_bind、netconn_listen、netconn_accept一路下去。send和recv也是经过netconn_write、netconn_recv完成的。为什么不直接用netconn？因为socket接口是网络编程的事实标准，资料多、代码迁移方便，LwIP用sockets.c这层把netconn包起来，纯粹是为了兼容使用习惯。

调试建议：如果socket层出现“recv返回0但抓包明明有数据”或者“连接假死”，先别急着怀疑协议栈。先在socket层打印errno，再看netconn层的接收缓冲余量，最后去TCP内核统计找线索。我遇到过很多次这类问题，最后定位出来都是接收窗口太小，或者应用线程没有及时调用recv，导致TCP滑动窗口被压到零。协议栈并没有错，是应用消费数据的节奏没跟上。

4.3 应用层apps目录与协议栈边界

src/apps目录里已经自带了一批可以直接编译的应用，包括httpd（Web服务器）、mqtt（MQTT客户端）、snmp、tftp、smtp、ping等。这些应用通过raw API或netconn实现，非常适合当“LwIP API正确用法”的范例来读。比如httpd的fs文件系统挂载机制、mqtt客户端的连接与心跳管理，都是非常典型的事件驱动写法。

但一定要记住，apps目录是官方附赠，不等于协议栈本体。思维导图上，我习惯用一条虚线把apps和核心协议栈隔开，旁边标注“可选，可整体裁剪”。产品不需要Web管理页面，整个httpd分支就可以折叠；不用MQTT，mqtt分支同理。很多人在工程里遇到apps目录下的编译错误，报一堆未定义宏，多半就是没按apps目录里的说明配置对应的LWIP_*开关，这属于看漏了每一棵分支自带的“说明书”。

5. 数据流在代码里怎么走：给思维导图加上流转线

5.1 收包路径：从PHY到应用

光有静态结构图还不够，真正的理解要靠动态数据流。我画完模块分支后，又用箭头在图上标了一条完整的收包链路。拿以太网收包举例：YT8512C这类PHY收到电平信号，还原成数据帧，经MAC和DMA写入内存描述符；驱动在中断里收到DMA完成中断，构建PBUF_POOL类型的pbuf，调用netif->input（通常是ethernet_input）把包送进协议栈；协议栈判断帧类型，IPv4帧交给ip4_input，IPv6帧交给ip6_input，ARP帧交给etharp_input；IP层查路由，如果目的地址是本机，就按上层协议号分发；TCP报文最终进入tcp_input，在tcp_in.c里查PCB表、走状态机，把数据放上接收队列；应用层通过tcp_recv回调（raw模式）或socket recv（顺序模式）把数据取走。

这条链路在思维导图里用带方向的箭头从上到下串起来。新手调不通网络时，只要在这条链路的每个节点打一条日志，立刻就能定位断在哪一环。我见过最多的坑是：PHY的link状态已经起来但收不到包，结果卡在DMA描述符没有正确分配；或者能收到ping的ARP请求但协议栈不回ARP，多半是etharp缓存池耗尽，不再学习新表项。

5.2 发包路径：从应用到PHY

发包路径相对简单一些。应用调用tcp_write或socket的send接口后，TCP层把用户数据复制成PBUF_RAM段，加上TCP头、计算校验和，放入发送队列；tcp_output根据当前窗口和拥塞窗口决定是立即发还是等定时器；IP层加上IP头，查询路由和ARP缓存拿到目的MAC地址；然后以太网驱动调用netif->linkoutput，把pbuf链拷贝到DMA描述符，MAC把帧发出去，PHY把电信号送上网线。中间任何一环的缓冲区满了，数据就会排队等待，等待超时再由重传机制处理。

这条线在思维导图上的要点是“发送缓冲（snd_buf）、等待确认、重传队列”三个节点。TCP_SND_BUF如果配得比应用单次写入的数据还小，就会出现write半成功或者阻塞等待；重传定时器如果配得过短，弱网环境里会出现毫无意义的疯狂重传，白白占带宽。

5.3 与CAN协议栈、CANopen的误区对比

看到相关热词里有“can协议栈”“canopen协议栈”，这里多说一句，因为确实有不少人把这几类概念混在一起。LwIP是TCP/IP协议栈，跑在以太网上，负责设备联网和数据交互；CAN是现场总线协议，跑在CAN总线上，CANopen是基于CAN的上层应用协议，负责工业现场的设备控制和实时数据交换。它们解决的问题不同，物理层不同，代码结构自然完全不同。你不需要为了用CAN去改LwIP，两者没有可替换关系。从思维导图的角度可以做一个类比：CANopen的“对象字典”类似LwIP的“PCB控制块”，都是协议内核里维护核心状态的数据结构；但实现细节没有任何互通性。同理，SD协议栈是存储领域的协议体系，和网络协议栈也完全是两套东西。画图时用“分层思想”去类比有助于理解，但千万别把代码结构本身搞混。

6. 实操演练：从零画出LwIP代码结构思维导图

6.1 工具选择与制图规范

工具上我试过好几种。XMind功能全、模板美观，适合出最终正式版；FreeMind开源免费、轻量，适合随手记录；draw.io适合把代码截图和结构图混排；甚至手绘白板也行。重点是“画出来”这个过程本身会强迫你去做模块归类，这才是最有价值的环节。我个人的流程是：第一遍用纸笔画草稿，边读源码边随手记模块归属和关键函数名；第二遍用XMind整理成正式版，补上目录路径和关键结构体；第三遍在模块之间画数据流箭头，形成最终版本。

制图规范我总结成三句话：粒度统一、层级一致、颜色区分。粒度统一，指每个叶子节点都停在“文件级或者关键结构体级”，不要出现一个节点是函数名、另一个节点却是目录名的情况；层级一致，指主干、枝干、叶子最多三层，超过就拆；颜色区分，指用不同颜色区分“官方核心”“可选应用”“用户移植代码”三类，一眼就能看出哪些代码归你维护。

6.2 推荐阅读顺序与入口函数

画图的同时要有一个合理的读码顺序，我的顺序是这样的，你也可以直接照抄：

第一步读init.c和lwip_init函数，理解协议栈初始化时会创建哪些内核对象、启动哪些线程，这是整个结构的起点；第二步读pbuf.c，搞清数据包的基本载体长什么样；第三步读mem.c和memp.c，搞清内存来源和分配策略；第四步读netif.c和ethernet.c，搞清楚网络接口如何注册、如何接入协议栈；第五步跑一个官方的最小例程，比如echo server，跟着tcp_new、tcp_bind、tcp_listen、tcp_accept走一遍TCP的完整生命周期；第六步再回头啃tcp_in.c和tcp_out.c里的状态机和重传细节，这时候你已经有了全图，细节只会越看越顺。

阅读每个文件时，我的习惯是：先读文件开头注释里的功能描述，再找结构体定义，再浏览对外API列表，最后才看函数实现。LwIP的注释做得相当好，很多关键函数都标注了“Called from”和“Calls”，这些信息正是画思维导图连线最好的素材，边读边抄，基本就能把模块间调用关系摸透。

6.3 避坑经验与常见问题速查

最后分享几个我实际踩过的坑，供你画图和调试时对照。

第一，别把lwipopts.h和cc.h搞混。lwipopts.h是功能裁剪配置，cc.h是编译器相关的数据类型、字节序、断言宏定义，两个头文件都要在编译包含路径里，缺一不可。我曾在一次工程整理时只保留了lwipopts.h，cc.h没拷贝全，编译报了一堆类型未定义，排查半天才发现是包含路径问题。

第二，画图时要把“接口函数”和“回调成员”区分开。比如tcp_recv既是应用层可以调用的接口函数，也是tcp_pcb结构体里的一个回调函数指针成员。两者同名，但一个是你调协议栈，一个是协议栈调你。画图时在叶子节点注明类型，否则后期翻图会被同名信息误导。

第三，LWIP_NETIF_LOOPBACK这个宏要理解清楚再配。它启用本地回环接口，用于本机进程间通信，但会让收发包路径多走一个循环分支。如果不做本机通信，建议关闭，减少无谓的代码路径，也让思维导图更干净。

常见问题速查表：

我在实际项目里画第一版图花了大约两个周末，之后每解决一个网络相关的bug，就往图上补一条“现象—排查路径”的备注。三个月后，这张图已经变成了我们小组内部的源码导航手册。新来的同事不用再从第一个文件通读，对着图按“入口到出口”的路径走两遍，基本就能独立上手改代码。

最后再分享一个小技巧：把完整的思维导图按“模块—文件—关键函数—配置宏”的结构导出成Markdown清单，塞进工程docs目录，每次git提交涉及协议栈改动时顺手更新一次。时间一长，这份清单就是整个项目最准确的LwIP代码地图，比网上任何教程都贴合你手头这套实际代码。我的体会是，画代码结构图这件事，画完那一刻的价值反而不如之后持续维护它的价值大。