1. 从一个真实调试场景说起：为什么UDP收发值得单独写一个Demo
很多做嵌入式网络开发的朋友，第一次接触LwIP协议栈时，往往是从TCP开始入手的——毕竟TCP有连接、有重传、有确认，看起来"更可靠"。但实际项目里，UDP才是那个绕不开的角色：设备状态广播、传感器数据上报、局域网设备发现、时间同步、日志推送，这些场景用UDP比TCP合适得多。原因很简单，UDP没有三次握手、没有拥塞控制、没有重传队列，协议栈的内存占用和CPU开销都小一大截，对于RAM只有几十KB的MCU来说，这个差别是决定性的。
但UDP的"简单"恰恰是它的坑所在。TCP帮你把连接管理、顺序保证、丢包重传都处理了，你只要读写流就行；UDP把这些全部交给应用层，协议栈只负责把数据报从A点搬到B点，搬丢了、搬乱了、搬重复了，它一概不管。所以一个能跑通的UDP Demo，价值不在于"能发能收"这四个字，而在于它把socket创建、绑定、发送、接收、超时处理、资源回收这条完整链路暴露给你看，让你知道每一环该怎么做、哪里容易出错。
这篇内容面向的是正在用LwIP做嵌入式网络开发的工程师，尤其是那些已经能把TCP跑通、但切换到UDP时遇到"发出去没反应""收不到数据""跑一会儿就卡死"这类问题的朋友。我会用一个典型的UDP回环Demo作为主线，把发送端和接收端的完整代码结构、参数含义、常见陷阱都拆开讲清楚。代码基于LwIP的socket API（也就是netconn之上的那层BSD风格接口），这套接口在裸机环境和RTOS环境下都能用，移植性最好。
需要提前说明的是，LwIP的UDP有两种编程接口：一种是raw API（回调式，零拷贝，效率最高但写起来反人类），另一种是socket API（阻塞式，接近Linux的写法，可读性好但多一层封装开销）。这篇Demo走的是socket API路线，因为绝大多数从Linux转过来的开发者对这个接口最熟悉，调试起来也最直观。如果你后面要做极致性能优化，再考虑往raw API迁移。
2. UDP socket在LwIP里的生命周期：从创建到销毁的完整链路
2.1 为什么UDP的socket创建比TCP更"轻"
在LwIP里创建一个UDP socket，核心就一行lwip_socket(AF_INET, SOCK_DGRAM, 0)。这里的SOCK_DGRAM就是数据报（datagram）的意思，和TCP的SOCK_STREAM（字节流）相对。这个参数决定了协议栈内部走的是udp_new()这条路径，而不是tcp_new()。
两者的区别体现在内存分配上。TCP的PCB（协议控制块）里要维护发送窗口、接收窗口、重传队列、定时器、拥塞状态变量，一个PCB动辄几百字节；UDP的PCB就简单多了，主要就是本地端口、远端地址端口、接收回调，几十字节搞定。我实测过在一个RAM 64KB的平台上，同时开20个TCP连接内存就紧张了，换成UDP开50个都还有余量。这就是为什么做设备发现、心跳广播这类"多对多"通信时，UDP几乎是唯一选择。
创建socket之后，UDP这边通常要做两件事：绑定本地端口和**（可选）连接远端地址**。绑定用lwip_bind()，把socket和一个本地IP+端口关联起来，这样协议栈收到目标端口匹配的数据报时，才知道该投递给哪个socket。如果不绑定，协议栈会给你分配一个临时端口，但接收端就不知道往哪发了，所以做服务端必须绑定。
至于lwip_connect()，UDP里它不产生任何网络报文，只是在内核里记录一下默认的对端地址。好处是之后发送可以直接用lwip_send()而不用每次填地址，接收时也会过滤掉非对端的数据报。这个技巧在客户端场景很好用，能省掉每次sendto填sockaddr的麻烦。
2.2 绑定地址时那个最容易踩的坑
绑定这一步，sockaddr_in结构体里有个字段叫sin_addr.s_addr，很多人习惯性写INADDR_ANY（也就是0.0.0.0），意思是"监听本机所有网卡的该端口"。这在有多个网络接口（比如同时有以太网和WiFi）的设备上是正确的做法。但如果你的设备只有一个网口，写INADDR_ANY和写具体IP效果一样，写具体IP反而更安全——因为它明确限定了只接收目标地址是这个IP的报文。
端口的选择也有讲究。0到1023是系统保留端口，虽然LwIP不像Linux那样严格限制，但为了避免和协议栈内部使用的端口（比如DHCP用的67/68、DNS用的53）冲突，应用层端口建议从1024往上选。我一般习惯用8000以上的端口，冲突概率低，调试时也好记。
还有一个隐蔽的坑：字节序。sin_port必须用htons()转成网络字节序，sin_addr.s_addr必须用htonl()。我见过太多人直接写addr.sin_port = 8080;，在小端平台上跑起来端口就变成了0x1F90的高低位颠倒，接收端怎么都收不到。这个错误编译不报错、运行不崩溃，就是不通，排查起来特别费时间。养成习惯：凡是往sockaddr_in里填的数字，一律过一遍htons/htonl。
2.3 关闭socket时的资源回收顺序
Demo跑完或者出错时，一定要记得lwip_close(sock)。UDP的socket虽然轻，但PCB、接收缓冲区这些资源不释放，反复创建就会耗尽内存池。LwIP的内存池（MEMP）数量是编译期固定的，在lwipopts.h里通过MEMP_NUM_UDP_PCB配置，默认值往往只有4到8个。如果你反复创建socket不关闭，跑到第9次就会返回失败，而且失败原因还不明显——lwip_socket返回-1，errno是ENOMEM，新手很容易懵。
正确的顺序是：先lwip_close()关闭socket，再处理其他清理。如果用了lwip_shutdown()，注意它只是关闭读写方向，不释放socket本身，最后还是要close。另外，如果socket是在一个任务里创建的，关闭也最好在同一个任务里做，避免多任务竞争导致的野指针问题。
3. 发送端实现：从数据打包到实际发出的每一步
3.1 发送缓冲区的组织方式
UDP发送的核心API是lwip_sendto()，原型是int lwip_sendto(int s, const void *data, size_t size, int flags, const struct sockaddr *to, socklen_t tolen)。参数看着多，其实逻辑很清晰：往sockets发送size字节的data，目标地址是to。
这里第一个要注意的是数据长度。UDP数据报的理论最大长度是65507字节（65535减去IP头20字节和UDP头8字节），但实际上受限于MTU。以太网MTU是1500，减去IP和UDP头，单个数据报的净荷最多1472字节。超过这个数，IP层会分片。分片本身没问题，但只要有一片丢失，整个数据报就废了，而且UDP不重传，所以实际项目里我强烈建议单包控制在1472字节以内，最好留点余量到1400左右。
如果你要发的数据超过这个长度，正确做法是在应用层自己分片，给每个分片加个序号，接收端重组。别指望IP分片，那玩意儿在丢包环境下的成功率低得感人。我做过一个测试，在有一定丢包率的链路上，发3000字节的UDP包（会分成3片），成功率不到70%；改成应用层分成3个1000字节的包分别发，成功率能到95%以上，因为丢一片只影响那一片，其他片还能收到。
发送缓冲区怎么组织？简单场景直接用一个栈上的数组就行，比如char tx_buf[128]。但如果数据是动态生成的，或者要发送结构体，建议用memcpy打包到一个固定缓冲区，而不是直接把结构体指针传进去。原因是结构体可能有字节对齐填充，不同编译器、不同平台的对齐方式不一样，直接发结构体过去，接收端解析出来就是乱的。稳妥的做法是手动逐字段序列化，或者用__attribute__((packed))强制紧凑排列（但这样访问效率会降低）。
3.2 发送返回值到底代表什么
lwip_sendto的返回值经常被误解。它返回的是成功交给协议栈的字节数，不是"对方收到了"。在UDP里，只要数据报成功进入了网络接口的发送队列，就算成功，返回的通常等于你传入的size。如果返回-1，才是真出错了，这时候要看errno。
常见的errno有这么几个：ENOMEM表示内存池不够，通常是发送队列满了或者PCB耗尽了；ENOBUFS表示缓冲区不足；EINVAL表示参数非法，比如socket没创建成功或者地址长度不对。我遇到最多的是ENOMEM，尤其是在高频发送场景下，网络接口发送速度跟不上应用发送速度，队列很快堆满。解决办法要么是降低发送频率，要么是增大lwipopts.h里的MEM_SIZE和PBUF_POOL_SIZE。
还有一个反直觉的点：UDP发送默认是阻塞的。如果发送队列满了，lwip_sendto会一直等，直到有空间。这在RTOS环境里可能导致任务卡死。解决办法是用lwip_fcntl把socket设成非阻塞，或者用lwip_setsockopt设置SO_SNDTIMEO发送超时。我一般推荐设超时，比如500毫秒，超时就丢弃这一包，记录一下日志，比整个任务卡住强。
3.3 一个完整的发送函数长什么样
把上面的点串起来，一个健壮的UDP发送函数大概是这样组织的：先检查socket有效性，然后填充目标地址结构体（注意字节序），调用lwip_sendto，检查返回值，处理错误。如果要做周期性发送，把这个函数放在一个定时任务里调用即可。
这里有个实操技巧：目标地址结构体可以复用。如果每次发送的目标都一样，没必要每次重新填sockaddr_in，在初始化时填一次，之后一直用就行。这样既省代码又省CPU。如果目标会变（比如广播给不同设备），那就每次填，但记得每次都要重新htons端口，别偷懒。
另外，发送频率的控制很重要。UDP没有流控，你发多快协议栈就尽力发多快，发不过来就丢。做传感器数据上报时，我一般会根据数据变化率来定频率，变化快就发勤点，变化慢就拉长间隔，而不是固定一个很高的频率傻发。这样既省带宽又省电。
4. 接收端实现：阻塞、超时与数据解析的取舍
4.1 recvfrom的阻塞行为与超时设置
接收端的核心是lwip_recvfrom()，它从socket的接收队列里取一个数据报，同时把发送方的地址填到传入的sockaddr里。默认情况下它是阻塞的：队列空的时候，调用它的任务会挂起，直到有数据到达。
阻塞模式在简单的单任务Demo里没问题，但在实际项目里往往不行。因为一个任务不能只干接收这一件事，它可能还要处理按键、刷新屏幕、控制外设。这时候就要用超时机制。LwIP里设置接收超时用lwip_setsockopt，选项是SO_RCVTIMEO，传一个struct timeval进去。设成比如1秒，那么recvfrom最多阻塞1秒，超时返回-1，errno是EAGAIN或EWOULDBLOCK。这样任务就能周期性地"醒过来"干别的事。
我个人的习惯是把接收超时设成100到500毫秒。太短了任务切换频繁，浪费CPU；太长了响应不及时。具体值看你的业务对实时性的要求。如果是做设备发现这种需要快速响应的，设100毫秒；如果是收日志这种不着急的，设1秒也行。
还有一种做法是非阻塞+轮询，把socket设成非阻塞，然后在一个循环里反复调recvfrom，没数据就干别的。这种方式实现简单，但CPU占用高，而且轮询间隔不好定。除非你的任务本身就是高频循环，否则我不推荐。
4.2 接收缓冲区的尺寸怎么定
recvfrom的第二个参数是接收缓冲区指针，第三个是缓冲区大小。这里的关键是：缓冲区要足够大，能装下对方可能发来的最大数据报。如果对方发来1472字节，你只给了512字节的缓冲区，recvfrom会返回-1，errno是EMSGSIZE，而且这个数据报会被丢弃，不会留在队列里等你下次用大缓冲区来取。
所以缓冲区尺寸要根据协议约定来定。如果双方约定单包不超过256字节，那给512字节缓冲区就够（留点余量）。如果不确定，直接给1472字节最保险，代价就是多占1.4KB的RAM。在RAM紧张的平台上，这个取舍要提前想清楚。
还有一个细节：recvfrom返回的是实际收到的字节数，不是缓冲区大小。所以拿到返回值后，要按实际长度去解析，别傻乎乎地按缓冲区大小去读，那样会读到一堆无效数据。
4.3 解析数据报时的字节序与对齐问题
收到的数据是一串字节，怎么解释取决于你的协议设计。如果发的是文本（比如JSON、CSV），直接当字符串处理就行。如果发的是二进制结构，就要注意字节序和对齐。
网络字节序是大端，而大多数MCU是小端。所以收到一个4字节的整数，不能直接memcpy到uint32_t就用，要先ntohl转换。浮点数更麻烦，因为IEEE 754的字节序转换没有标准函数，得自己写或者用联合体（union）手动转。我的建议是：协议里尽量用整数，避免浮点。如果非要用浮点，发送端先转成定点整数（比如乘以1000变成毫整数），接收端再除回来，这样跨平台最稳。
对齐问题前面提过，发送端如果直接发了结构体，接收端解析时可能因为对齐差异读错字段。解决办法是接收端也定义同样的packed结构体，或者干脆逐字节手动解析。手动解析虽然代码长，但最可靠，我一般推荐这种方式。
5. 调试UDP时那些让人抓狂的现象与排查思路
5.1 "发出去了但对方没收到"的三层排查法
这是UDP调试里最高频的问题。我的排查顺序是从下往上：先确认物理链路，再确认IP层，最后确认UDP层。
物理链路层，看网口的link灯亮不亮，用ping能不能通。如果ping都不通，那跟UDP没关系，先解决网络连通性。IP层，确认双方的IP在同一网段、子网掩码一致。我遇到过好几次是设备IP配成了192.168.1.x，而对方是192.168.0.x，网关又没配，包根本出不去。
UDP层，用抓包工具（比如在PC端跑一个抓包软件，或者用带镜像口的交换机）看包到底发出来没有。如果抓到了发送包但接收端没收到，那可能是接收端防火墙拦了、端口没绑定对、或者绑定到了错误的网卡。如果连发送包都没抓到，那就是发送端的问题，检查sendto返回值、目标地址填对没有。
这个三层排查法能覆盖90%的"发不出去"问题。剩下的10%往往是更隐蔽的，比如MTU不匹配导致大包被丢、或者中间有设备做了UDP限速。
5.2 接收端"跑一会儿就收不到了"的内存泄漏
这个现象很典型：Demo刚跑起来正常，收发几十次之后就卡死，重启又好了。十有八九是接收缓冲区没释放或者socket没正确关闭。
在LwIP的socket API里，recvfrom取走数据后，底层的pbuf会自动释放，这个不用你管。但如果你用的是raw API，就必须自己调pbuf_free，忘了就会泄漏。socket API虽然省心，但如果你在接收循环里动态分配了内存（比如malloc了一个缓冲区来存数据），用完忘了free，一样会泄漏。
还有一种情况是接收队列溢出。LwIP给每个UDP socket维护一个接收队列，队列长度由lwipopts.h里的UDP_RECV_BUFSIZE或者MEMP_NUM_PBUF间接决定。如果应用层接收速度跟不上发送速度，队列满了之后新来的包会被直接丢弃，而且不通知应用层。表现就是"跑一会儿收不到了"，其实是队列一直满着，新包进不来。解决办法是提高接收任务的优先级，或者增大队列长度，或者让发送端降速。
5.3 广播和多播场景下的特殊处理
做设备发现时经常要用广播（目标地址255.255.255.255）或者多播（224.0.0.x）。这两种场景和单播有几个不同点。
广播发送时，sendto的目标地址填广播地址，但必须设置SO_BROADCAST选项，否则会返回EACCES错误。这个选项用lwip_setsockopt设置，值是1。很多人不知道这一步，广播发不出去还以为是协议栈不支持。
多播接收时，除了绑定端口，还要加入多播组。LwIP里用lwip_setsockopt的IP_ADD_MEMBERSHIP选项，传一个ip_mreq结构体，里面填多播组地址和本地接口地址。不加这一步，多播包到了网卡也会被协议栈过滤掉。
还有一个坑：广播包在有些网络设备上会被限速或者直接丢弃，尤其是跨网段的时候。所以广播适合做局域网内的设备发现，不适合做跨网段通信。跨网段要么用单播，要么用多播（前提是网络设备支持多播路由）。
6. 从Demo到产品：几个值得提前考虑的工程化问题
6.1 把收发逻辑封装成独立模块
Demo里把收发代码写在一个函数里没问题，但产品里最好封装成一个独立的UDP模块，对外提供udp_init、udp_send、udp_recv、udp_deinit这几个接口。这样上层业务不用关心socket细节，换协议栈或者改配置时也只动这一个模块。
封装时要注意线程安全。如果多个任务都要发送，而socket是共享的，那就要加互斥锁。LwIP在RTOS模式下提供了sys_mutex系列接口，或者直接用你RTOS自带的互斥量。接收端一般只有一个任务在收，不用加锁，但如果多个任务都要收同一个socket，那就要考虑用消息队列把数据转发出去，而不是让多个任务抢着调recvfrom。
6.2 心跳与超时检测的设计
UDP没有连接状态，所以"对方还在不在"需要应用层自己判断。常见做法是双方定期互发心跳包，比如每秒一次，连续3秒没收到就认为对方离线。这个逻辑要放在应用层，协议栈帮不了你。
心跳包的设计也有讲究。包体要尽量小（几个字节就够），但要包含一个序号，这样接收端能判断有没有丢包、有没有乱序。序号还能用来做简单的去重——收到重复序号的心跳直接丢弃，避免重复处理。
6.3 错误处理与日志记录
产品环境里，UDP出错是常态，不能一出错就重启。我的做法是：发送失败时记录errno和失败次数，连续失败超过阈值才上报异常；接收超时是正常的，不记录；接收返回EMSGSIZE说明对方发了超长包，记录一下对方的IP和端口，方便排查。
日志本身也要注意别用UDP发，因为日志量大时UDP丢包严重，关键日志可能丢。重要日志走串口或者本地存储，UDP只用来发非关键的运行状态。
6.4 性能调优的几个参数
如果Demo跑通后发现吞吐量上不去，可以调这几个参数：MEMP_NUM_UDP_PCB（UDP控制块数量）、PBUF_POOL_SIZE（pbuf池大小）、MEM_SIZE（堆大小）、TCPIP_MBOX_SIZE（协议栈邮箱大小）。具体调多少要看你的平台资源和业务量，没有万能值。我的经验是先看lwip_stats里的memp和pbuf统计，哪个耗尽就加哪个，别盲目全加，RAM是有限的。
还有一个容易忽略的点：网卡驱动的发送/接收缓冲区。LwIP只是协议栈，真正收发数据的是网卡驱动。如果驱动的缓冲区太小，协议栈再优化也没用。调优时要软硬一起看。
7. 写在最后的一点个人体会
UDP这个协议，用起来简单，用好很难。它的所有"坑"本质上都源于一个事实：它把可靠性、有序性、流控这些责任全部推给了应用层。所以写UDP代码时，脑子里要始终绷着一根弦——我发的包可能丢、可能乱序、可能重复，我的代码能不能扛住这些情况。
我刚开始做嵌入式网络时，也觉得UDP比TCP简单，结果第一个项目就栽在"以为发出去了对方一定收到"这个假设上。后来慢慢明白，UDP的正确用法不是"发出去就完事"，而是"发出去之后，用应用层的机制去确认、去重传、去兜底"。这个思路转变过来之后，UDP反而成了我最喜欢的协议——因为它可控，每一层逻辑都在我手里，出了问题我知道去哪找。
这个Demo的代码量不大，但把socket创建、绑定、发送、接收、超时、关闭这条链路完整走了一遍。建议你在自己的平台上把它跑通之后，再试着改几个参数：把接收超时从1秒改成100毫秒看看任务切换频率的变化，把发送缓冲区从128字节改成1472字节看看大包的表现，把socket设成非阻塞看看轮询的CPU占用。这些实验做下来，你对LwIP UDP的理解会比看十篇文档都深。
