从浏览器直接看温湿度：嵌入式Web Server与以太网传感器实战解析

前两天帮朋友调一个机房环境监控的小项目需求很简单机房角落里放几台设备想实时盯着温度和湿度但又不想装一堆客户端软件更不想把数据往第三方云平台送。我直接给方案定了“以太网温湿度传感器 内置Web Server”这条路子浏览器打开就能看局域网里任何一台电脑手机都能访问完全不需要装额外的东西。这套方案在嵌入式物联网场景里特别实用而且在浏览器、Web Server、以太网这几个关键词背后其实是整个硬件和网络协议的配合过程。这篇就把我在实际做这个项目时的完整思路、硬件选型、固件实现和填坑记录都写出来给正准备做类似“传感器上云/上内网”项目的朋友做个参考。1. 方案定位与设计思路拆解1.1 一个能开网页的传感器解决的到底是什么问题先说需求。机房、仓库、温室大棚、实验室这些场景普遍存在一个共同痛点需要监测温湿度但数据必须在现场看或者只在内网流转。以前常见的做法是拿个串口屏或者USB转串口接电脑再装个上位机软件数据只能在那一台电脑上看。后来流行过一阵WiFi模块MQTT的方案数据往云平台推但很多工业现场和内部机房对数据出网有严格限制云平台那条路根本走不通。这时候“传感器直接内置Web Server”的思路就很香了。我做的这个设备本质上就是一块板子MCU负责读传感器SPI接一个以太网芯片再通过RJ45网线连交换机或路由器。设备通电后自动获得一个内网IP你用浏览器输入这个IP直接就能看到当前温度、湿度和采集时间。整个过程不依赖任何上位机软件、不依赖云平台、不依赖操作系统单片机自己把HTTP协议处理了。多台设备就是多几个IP浏览器标签页一开所有数据一目了然。这个方案的杀手锏是跨平台。Windows、macOS、Linux、Android、iOS只要有浏览器就能看这在团队协作场景里非常爽。设备维护人员不用在被监测电脑上装软件也不用学习上位机的操作逻辑打开网址看数据这个动作谁都会。1.2 同场竞技以太网Web Server对比串口、WiFi、蓝牙方案选型阶段我列过一张对比表把主流的几种传感器数据传输方案横向拉了一下。这里直接放出来是我当时做决策的核心依据。方案传输距离布线成本客户端要求数据上云/上内网可靠性适用场景串口(RS232/USB)短(15m内)低需上位机软件需主机中转中台式机本地调试蓝牙BLE极短(10m)无需配网/App需手机中转中个人近距离查看WiFi(ESP8266等)受路由覆盖影响无浏览器/App方便但信号易受干扰中家庭/办公环境以太网Web Server100m(标准UTP)网线部署仅浏览器直接内网可达高机房/工业现场/长期监测串口方案最大的问题是“数据被绑定在一台机器上”而且上位机软件通常要买授权或者自己写工程现场最烦的就是软件环境兼容性。蓝牙方案其实是近距离调试用的真拿去机房部署手机连哪个设备还得配对多设备监测体验很差。WiFi方案看似灵活但在实际项目中碰到过不少坑AP信号不稳、设备掉线重连慢、路由节能模式把连接睡了而且很多工业现场根本不部署无线网络。以太网方案在这些场景里是最稳的。网线供电和传输一体100米的覆盖半径在不大的机房和仓库里完全够用。更重要的是以太网通信本身是成熟到不能再成熟的技术没有无线信号干扰问题设备该通就通不该通大概率就是网线没插好或者IP配错了排查路径非常清晰。内置Web Server之后前面说的客户端软件成本、跨平台问题全部消失。1.3 为什么选择硬件协议栈方案W5500的取舍逻辑以太网通信在嵌入式上做其实有两条技术路线。一条是用MCU自带MAC或者裸的PHY芯片比如STM32F407的MACLAN8720然后在固件里跑LwIP这样的软件协议栈。另一条就是我用W5500这种自带硬件TCP/IP协议栈的芯片MCU只需要通过SPI往寄存器里读写数据TCP、UDP、ICMP这些协议全部由芯片自己完成。W5500方案对单片机来说压力小得让人感动。我用的主控是那颗经典的STM32F103C8T6也就是大家常说的“蓝丸”芯片主频72MHzFlash只有64KB。如果用LwIP光协议栈代码和缓冲就得吃掉几十KB的Flash和大量RAMF103C8的资源配置起来非常紧张还得折腾内存池和零拷贝这些细节。而W5500把TCP/IP协议栈做死在芯片内部MCU这边只需要维护SPI通信和简单的Socket状态机Flash空间主要留给业务逻辑就行。当然这个选择也有代价。W5500内部有独立的TX/RX Buffer总共32KB分成8个Socket每个Socket最大能分16KB收发缓冲区。这个配置做HTTP Server其实绰绰有余因为我传的数据就是几KB的HTML页面和温湿度数值一个客户端连接根本不占多少资源。但如果你要做的是一台高并发的Web服务器那就别指望这点缓存了那本来就是Linux和Nginx的地盘。工业级传感器Web Server这个特定场景W5500就是性价比和开发效率的最优解。2. 硬件选型与电路连接要点2.1 传感器怎么挑DHT11、DHT22还是SHT3x温湿度传感器在项目里是最容易被低估但又最容易翻车的一环。市面上最常见的三款是DHT11、DHT22(AM2302)和SHT3x系列。我第一版用DHT11做的后面发现精度不够又换了DHT22最后批量做的时候用了SHT30。DHT11的价格最低但精度说实话比较感人温度精度正负2摄氏度湿度精度正负5%RH而且采样周期要求不低于1秒。它内部用的是电阻式测湿元件和NTC测温元件响应速度很慢。如果你只是看个大概环境变化趋势DHT11够用但如果要用来做设备运行环境合规监测这个精度又有点说不过去。另外DHT11的单总线时序对延时精度很敏感我之前在FreeRTOS环境下读DHT11任务调度偶尔会造成时序漂移读出来的数据校验就报错。DHT22把精度提升到温度正负0.5摄氏度、湿度正负2%RH价格也就贵几块钱性价比很高。它和DHT11用同样的单总线协议但数据位定义不一样DHT22是16位湿度、16位温度最高位是符号位。要注意的是DHT22的湿度分辨率是0.1%RH在0到100%RH范围内线性度比DHT11好很多。我最后在样机阶段用了DHT22总体表现稳定。SHT3x是I2C接口的数字传感器精度最高温度能做到正负0.2摄氏度湿度正负1.5%RH。它的好处不仅仅是精度更重要的是I2C数字通信不受时序抖动影响固件端读取非常稳定。工业场景如果预算允许建议直接上这一档。我在后面的批量版本里就换成了SHT30代码改动也不大因为上层都是一层“读取传感器返回温湿度结构体”的抽象底层换驱动就行。2.2 以太网芯片W5500、ENC28J60、LAN8720怎么选以太网接口这块除了W5500市场上还经常见到ENC28J60和LAN8720。这三者很容易让人晕我直接说结论。W5500是自带TCP/IP协议栈的MACPHY集成芯片SPI接口核心优势是开发简单。主机MCU不需要知道TCP握手、数据包分片这些细节直接把Socket打开写数据读数据就行。它的SPI通信速率最高到80MHz左右实际跑下来一个HTTP请求的响应速度毫秒级对传感器这种低频小数据量场景绰绰有余。ENC28J60是老前辈了但它严格来说只包含MACPHY没有硬件TCP/IP协议栈你必须自己在MCU端跑uIP或LwIP。而且它只有8KB的收发缓冲大一点的IP包就得做分片处理固件复杂度直接上一个档次。我在老项目上被它折腾过掉包、缓冲溢出各种问题所以新项目从来不用。LAN8720则是纯PHY芯片连MAC都要MCU自带的以太网控制器来配合还必须上LwIP软件协议栈。它的性能上限最高100Mbps但开发难度也最高需要配置MAC地址、MDIO管理接口、RMII时序。除非你追求100Mbps的吞吐否则拿它做传感器Web Server有点杀鸡用牛刀。我的最终选择是W5500最经典的版本外加板载网络变压器和RJ45座。选带网络变压器的模块可以避免自己在PCB上画变压器的麻烦而且不少模块直接集成了12MHz晶振和必要的滤波电容外围电路基本为零。模块如图书页大小的蓝色小板出线直接连SPI和电源就能用。2.3 硬件连接与供电经验W5500模块和STM32的连接方式已经非常成熟了。标准接法是SPI四根线加两根控制线我用的引脚分配如下方便你直接抄。功能W5500模块STM32F103C8T6引脚SPI时钟SCLKPA5(SPI1_SCK)SPI主机输出/从机输入MOSIPA7(SPI1_MOSI)SPI主机输入/从机输出MISOPA6(SPI1_MISO)SPI片选CSPA4(软件控制)复位RSTNPA3(软件控制)中断INTNPA2(外部中断可选)W5500芯片的IO电平兼容3.3V但片内对5V输入也做了容忍从5V单片机引脚直连问题不大。STM32F103本来就是3.3V系统直接连就行不用加电平转换。供电方面要特别注意W5500模块上的网络变压器中心抽头需要3.3V供电如果电源纹波比较大会直接影响网络信号质量。我实测过用同一个LDO给MCU和W5500供电当板的系统总电流超过150mA时网络传输会出现偶发丢包。建议W5500的3.3V单独用一个低噪声LDO或者至少在主LDO输出端加一个10uF陶瓷电容和一个100uF钽电容做去耦。DHT22传感器接在PB12上外部加上一个4.7kΩ上拉电阻到3.3V。单总线协议要求设备空闲时总线保持高电平没有上拉电阻会直接导致通信失败。SHT30如果要用I2C版本就接PB6(I2C1_SCL)和PB7(I2C1_SDA)地址线ADDR接低电平从设备地址是0x44。还有个小细节电源滤波电容要尽量靠近W5500模块的电源引脚最好控制在5mm以内。我在第一版PCB上就是因为电容放得远导致高频噪声滤不掉Web Server偶发卡顿查了一天才定位到是电源问题。3. Web Server固件实现从底层HTTP到数据页面3.1 浏览器访问一个IP时发生了什么固件层面最核心的其实是搞懂HTTP协议的最小模型。很多人一听“在单片机上写Web Server”就觉得很难其实拆开看就几个动作。浏览器在地址栏输入设备的IP比如192.168.1.100它会往这个IP的80端口发起一个TCP连接。TCP三次握手完成之后浏览器会发送一个HTTP请求报文。这个报文长这样GET / HTTP/1.1 Host: 192.168.1.100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) ... Accept: text/html Connection: keep-alive重点是第一行“GET / HTTP/1.1”是请求行表示用GET方法请求根路径后面的是请求头浏览器会带一堆信息但对我们来说大部分都是废的。Web Server真正需要关心的就是请求行里的方法(GET/POST)和URL路径(/、/data、/favicon.ico这种)。单片机端Web Server收到这个请求后需要回一个HTTP响应报文。响应也分三部分状态行、响应头、响应体。最小可用的响应是这样HTTP/1.1 200 OK Content-Type: text/html; charsetutf-8 Content-Length: 345 Connection: close html...页面内容.../html状态行里的200表示成功404就是找不到资源。Content-Type告诉浏览器这是HTML文档charsetutf-8是防止中文乱码的关键很多人页面中文变乱码就是漏了这行。Content-Length必须填对浏览器按这个长度读取响应体填多了浏览器会等超时填少了数据被截断。在固件里实现HTTP响应核心就是拼字符串。MCU收到请求后判断是根路径就把一个HTML页面字符串通过TCP Socket发送出去发送完毕后主动关闭TCP连接。整个流程对W5500来说就是几个寄存器的操作打开Socket、监听端口、接收数据、写入发送缓冲区、发送、关闭。3.2 固件主循环与TCP Socket状态机W5500库的写法很多官方有ioLibrary但直接拿来做HTTP Server还是要理清状态机。我的主循环架构非常简单清晰就是“轮询中断标志”。while (1) { // 1. 周期读取温湿度传感器建议最低间隔2秒 if (read_sensor_flag) { temp read_temperature(); humi read_humidity(); read_sensor_flag 0; } // 2. 处理W5500的Socket事件 w5500_loop(); // 3. 其他低优先级任务 systick_handler(); } void w5500_loop(void) { uint16_t len; uint8_t buf[512]; switch (getSn_SR(SOCK_TCPS)) { case SOCK_CLOSED: socket(SOCK_TCPS, Sn_MR_TCP, 80, 0x00); break; case SOCK_INIT: listen(SOCK_TCPS); break; case SOCK_ESTABLISHED: len getSn_RX_RSR(SOCK_TCPS); if (len 0) { len recv(SOCK_TCPS, buf, sizeof(buf)); parse_http_request(buf, len); send_http_response(SOCK_TCPS); close(SOCK_TCPS); } break; default: break; } }这个循环的关键是W5500的Socket状态迁移。Socket刚上电是CLOSED调用socket()函数创建TCP Socket后变成INIT调用listen()进入监听状态有浏览器连上来并完成三次握手后变成ESTABLISHED。此时接收缓冲区里就有HTTP请求数据了用recv()读出来解析一下URL路径然后发送HTTP响应最后调用close()把连接关掉。这里有一个很多新手容易踩的坑close()之后W5500的Socket会进入FIN_WAIT状态底层TCP会完成四次挥手。如果你马上重新调socket()创建新Socket可能会因为旧连接还没完全释放而出错。我的做法是close之后延时100ms再做下一步给W5500一点时间把状态机转完。后来排查到这个问题是因为客户反馈“刷新页面偶尔会失败”抓包发现是Socket被快速重开时资源还没释放完。3.3 读取温湿度单总线时序与数据解析DHT22读取在固件端也是个经典环节。虽然表面上是两根线但时序要求非常严格。我用的是标准流程主机先把总线拉低至少18ms之后释放并拉高20到40微秒然后等待DHT22响应。DHT22响应是一个80微秒的低电平再加一个80微秒的高电平之后连续输出40位数据。每一位数据的开始都是一个50微秒的低电平接着是高电平的时间长短区分0和1高电平持续26到28微秒是0持续70微秒是1。单片机端要精确测量这个高电平的持续时间在72MHz的STM32上可以用定时器输入捕获或者简单的Delay循环配合读取GPIO电平。uint8_t dht22_read_data(float *temperature, float *humidity) { uint8_t data[5] {0}; uint8_t i, j; // 发送起始信号 DHT_GPIO_MODE_OUT(); DHT_LOW(); delay_ms(20); DHT_HIGH(); delay_us(30); DHT_GPIO_MODE_IN(); // 等待响应 while (GPIO_ReadInputDataBit(DHT_PORT, DHT_PIN)); // 等待低电平 while (!GPIO_ReadInputDataBit(DHT_PORT, DHT_PIN)); // 等待高电平 while (GPIO_ReadInputDataBit(DHT_PORT, DHT_PIN)); // 等待数据起始 // 读取40位数据 for (i 0; i 5; i) { for (j 0; j 8; j) { while (!GPIO_ReadInputDataBit(DHT_PORT, DHT_PIN)); // 等待低电平结束 delay_us(40); if (GPIO_ReadInputDataBit(DHT_PORT, DHT_PIN)) { data[i] | (0x80 j); } while (GPIO_ReadInputDataBit(DHT_PORT, DHT_PIN)); // 等待高电平结束 } } // 校验 (前4字节之和取低8位等于第5字节) if ((uint8_t)(data[0] data[1] data[2] data[3]) ! data[4]) { return 1; // 校验失败 } *humidity ((data[0] 8) | data[1]) / 10.0f; *temperature ((data[2] 8) | data[3]) / 10.0f; return 0; }这个代码里最敏感的地方是delay_us(40)。如果用的是HAL库的HAL_Delay最小精度是1ms根本做不了微秒级延时。我当时用的是正点原子风格的Delay函数用SysTick做微秒延时实际误差在2微秒以内满足DHT22的时序要求。如果你在RTOS环境里跑这个代码记得在这段函数里加临界区保护否则任务抢占会让时序完全乱掉。DHT22读取失败的时候返回一个错误标记Web Server端就显示“--”而不是一个错误的数值这个习惯能省掉很多排查时间。3.4 页面设计与数据自动刷新温湿度数据显示页面不用花哨但要做到两个点自动刷新、一眼看懂。我第一版用的是最古老但最稳的meta refresh方式在HTML的head里加一行meta http-equivrefresh content5这样浏览器每5秒自动重新加载一次页面MCU端每次收到GET请求时现读取一次温湿度传感器动态拼到HTML里返回。这个方案实现成本最低但对嵌入式设备来说有一个问题每次刷新都是全量页面一个页面大约1.5KB每5秒一次长时间运行下来MAC层虽然没问题但浏览器端的加载感比较明显而且如果无线网络环境差一点整页刷新反而容易白屏。不过在有线以太网W5500的场景下这个缺点其实不明显我在项目里实际用的就是这个方案稳定跑了一周都没掉过链子。第二版我实现了更优雅的方式页面框架静态加载一次之后用JavaScript的XMLHttpRequest定时去请求一个“/data”接口这个接口返回纯文本温湿度值。这样做的好处是页面框架不重新加载只有数据部分每10秒轮询一次用户体验更好而且数据请求的HTTP响应体更小。单片机端需要解析不同的路径GET / 返回完整HTML页面GET /data返回“25.3, 60.2”这样的字符串。JavaScript那边解析字符串后直接更新DOM元素的innerText比正则解析JSON省事多了。function refreshData() { var xhr new XMLHttpRequest(); xhr.open(GET, /data, true); xhr.timeout 2000; xhr.onload function() { if (xhr.readyState 4 xhr.status 200) { var parts xhr.responseText.split(,); document.getElementById(temp).innerText parts[0] ℃; document.getElementById(humi).innerText parts[1] %RH; } }; xhr.send(); } setInterval(refreshData, 10000);这里要特别提醒一个W5500并发处理的问题。当浏览器发起/data请求时如果上一次的页面请求连接还没完全关闭W5500的8个Socket够不够用放心够。一次只开一个Socket监听80端口收到请求后可以用同一个Socket响应并关闭。一个浏览器同时段只会维持一两个TCP连接到同一台设备8个Socket理论上同时支持7个客户端并发都没问题。但要注意同一时刻只能有一个Socket在listen()状态否则W5500会报Socket冲突这个坑我在多Socket配置时踩过一次。4. 实际操作流程与配置步骤4.1 准备清单从硬件到软件的完整列表在实际动手之前我把整个操作流程整理成了一份清单照着准备就不会漏东西。硬件方面我需要STM32F103C8T6最小系统板一块、W5500以太网模块一块、DHT22温湿度传感器一个(或DHT11/SHT30)、标准网线一根、路由器或交换机一台、5V/1A以上的USB电源一个。软件方面则需要STM32的编译工具链(我用的是Keil MDK)、W5500的驱动库(官方ioLibrary或者自己写的简化版)、任意一款现代浏览器(Chrome、Edge或者Firefox都行)。如果你打算直连电脑不经过路由器还需要手动配置电脑的IP地址为同一网段比如设备设192.168.1.100电脑就设192.168.1.50。这块特别注意一点W5500的官方库里面有很多针对不同型号的宏定义用F103的时候记得把WIZCHIP和WIZCHIP_IO_MODE这些宏配置正确我用ST的HAL库做SPI底层对接时把Spi读写函数封装成WIZCHIP_READ_BUF和WIZCHIP_WRITE_BUF再和官方库挂接上就完事了。如果连官方库都懒得理只写一个精简驱动也完全够用毕竟Web Server只需要Socket的open/listen/recv/send/close这几个核心API。4.2 网络参数设置静态IP和DHCP的取舍网络配置这块我的建议很简单固定IP。HTTP Server设备在网络里是一个服务端身份IP地址应该保持稳定。如果你让设备用DHCP自动获取地址路由器一重启设备可能就换IP了原来浏览器收藏夹里的地址就失效了这对运维来说非常痛苦。我做的设备支持两种模式但默认是静态IP比如192.168.1.100、网关192.168.1.1、子网掩码255.255.255.0。静态IP的初始化配置在固件里就三行代码// 配置W5500为静态IP uint8_t ip[4] {192, 168, 1, 100}; uint8_t gw[4] {192, 168, 1, 1}; uint8_t mask[4] {255, 255, 255, 0}; setSHAR(mac); // 设置MAC地址 setSIPR(ip); // 设置IP地址 setGAR(gw); // 设置网关 setSUBR(mask); // 设置子网掩码MAC地址需要自定但要注意不能和局域网内其他设备的MAC冲突也不要乱选到广播组播地址段。我习惯用00:08:dc:xx:xx:xx这种前缀WIZnet官方模块的MAC前缀也是00:08:dc。自己批量做设备时建议在程序里保存一个基于序列号的MAC尾号避免每台设备MAC雷同。虽然同一个局域网里两台设备MAC相同会导致路由器ARP表抖动、网络时断时续这种问题排查起来比配置问题难多了。DHCP模式在我这个项目里作为备选实现。W5500 ioLibrary里带DHCP客户端跑起来之后会自动从路由器拿IP。但有个坑DHCP客户端需要周期性地发送租约续期请求否则IP会被路由器收回。如果主循环里长时间卡在HTTP请求处理上DHCP续期延时了IP过期后路由器的ARP表会清掉对应条目设备就“失联”了。这个场景在长时间运行的设备上尤其明显我有一台测试机就是跑到大概24小时左右突然失联日志查了才发现是DHCP租约没续上。后来直接把该模式设为非默认选项只在诊断时用。4.3 浏览器访问和验证效果配置完固件并烧录进STM32后整个系统的验证流程一共就四步。第一步给设备供电插上网线。看W5500模块上的Link指示灯是否亮起这个灯亮表示物理链路是通的网线或交换机端口已经协商成功。第二步在浏览器里输入设备IP地址比如http://192.168.1.100然后回车。如果页面正常显示温度和湿度说明Web Server和传感器读取链路都是通的。第三步打开电脑的命令行使用ping工具对设备IP执行连通性测试。丢包率应该是0如果出现明显丢包优先检查网络变压器附近的电源滤波其次检查网线质量。第四步用浏览器开发者工具(按F12)的Network面板查看请求列表确认页面加载请求和/data请求都返回200状态码。这一步属于进阶验证能帮你排除很多“页面看着正常但数据不更新”的隐形问题。浏览器这块我还想多说一句项目上线以后最好留一个固定浏览器作为“标准客户端”。我之前遇到过用某个安全浏览器访问设备页面时页面被“智能拦截”提示风险原因是设备HTTP响应里没有X-Frame-Options头被一些浏览器误判为潜在不安全页面。后来我干脆在设备页面里加入了X-Frame-Options: DENY响应头情况才好转。这个问题的核心不是设备本身不安全而是浏览器策略越来越严格。4.4 数据对外提供API给后续监控平台留接口做Web Server不只是给人看更多时候是为了给别的系统提供数据。我在设备上额外实现了一个/api/temperature和/api/humidity的GET接口返回格式是纯文本数值。这样内网监控平台通过HTTP请求就能把数据抓到自己的数据库比如用Python的requests库每10秒拉一次存到InfluxDB或者MySQL里做历史曲线。API接口的实现就是前面说的URL路径解析在parse_http_request函数里用strncmp判断路径if (strncmp(req_path, /api/temperature, 16) 0) { snprintf(payload, sizeof(payload), %.1f, temperature); send_http_response(200, text/plain, payload); } else if (strncmp(req_path, /api/humidity, 13) 0) { snprintf(payload, sizeof(payload), %.1f, humidity); send_http_response(200, text/plain, payload); } else { send_http_response(404, text/plain, Not Found); }很多人觉得在单片机上做API接口很麻烦其实HTTP协议本身就是文本协议只要做好字符串解析API和网页本质上没有区别。设备端的固件里甚至不需要保存任何历史数据所有历史记录都由更上层的监控平台去存。这种设计有一个好处设备固件保持简单设备和平台解耦以后哪怕把监控平台换了设备端代码一行都不用改。这个思路对长期维护的系统特别重要传感器设备本身的职责就是把实时数据准确送出去至于数据怎么存、怎么展示那是平台层的事。5. 常见问题与排查技巧实录5.1 高频故障对照表做这类项目最容易遇到的问题其实不多我把实际工程里出现的和高频网络讨论里的典型问题汇总成了一张排查表后面遇到相同情况直接照着查就行。现象可能原因排查方法解决方案浏览器打不开页面设备IP不在同一网段命令行看本机IP对比设备IP修改本机IP或设备IP到同一网段浏览器一直转圈不响应TCP连接建立不了Socket状态卡死查看设备日志或串口输出Socket状态给close()后加延时确保Socket彻底释放页面打开但温湿度显示--传感器读取失败代码里打印传感器错误码检查上拉电阻、接线、时序参数数据能显示但一旦刷新就掉线W5500快速开关Socket导致资源未释放连续多次刷新页面观察Socket状态close后加100ms延时再重新listen中文乱码响应头缺少charsetutf-8F12看响应头信息在Content-Type中补充charsetutf-8ping不通设备但Link灯正常IP/MAC配置错误或ARP缓存问题电脑上ping完后查arp -a表确认MAC和IP配置正确清ARP缓存重试设备运行一天后失联DHCP租约过期(如果开了DHCP)查路由器的DHCP客户端列表改用静态IP网页偶尔加载很慢W5500电源噪声导致丢包重传观察交换机端口错误计数加强电源滤波LDO单独给W5500供电这份表格里我标出来的第一条和第六条是现场最容易遇到又不能互相替代的。第一种是纯粹的网络配置不对电脑和设备不在同一网段访问当然失败。第六种是物理链路通但逻辑不通可能性就多了设备MAC冲突、IP冲突、ARP缓存污染逐一排查耗时比较长。我自己的排查习惯是先pingping不通就查ARP表ARP表看不到设备MAC就查物理链路物理链路没问题再查设备侧配置按照这个顺序很少有人能难倒你。5.2 那些不写在文档里的避坑经验最后分享一些这个项目真正磨人的地方这些经验是我在调试过程中一点一点攒出来的常规教程里基本不会提到。第一个坑是关于TCP连接关闭方式的。HTTP/1.1默认是keep-alive长连接浏览器打开页面后会保持连接然后询问服务器是否需要复用。如果设备端简单粗暴地close()浏览器可能会报连接被重置的错误。后来我直接把响应头里的Connection: close加上明确告诉浏览器“我给你发完响应就关连接”这个报错就消失了。看似很小的一个头字段其实是服务器端主动管理连接生命周期的规范做法。第二个坑是W5500的中断引脚问题。W5500的INTN引脚在收到数据、Socket状态变化时都会拉低。我最早把它接到单片机的EXTI中断上每次中断都要读W5500的中断源寄存器、Socket中断寄存器来确认到底是谁触发的代码逻辑绕来绕去反而容易漏处理。后来我改成在主循环里定时轮询Socket的接收数据寄存器大小虽然“浪费”了几毫秒但逻辑清晰了很多也没有丢过数据。对低速传感器场景轮询明显比中断更抗造。第三个坑关于页面转义。如果你要把设备型号、固件版本这些字符串拼到HTML页面里返回记得先做HTML转义。有一个已知场景是设备命名时带了“”字符结果HTML解析把它当成实体引用的起始符号导致页面显示异常。这个坑在Web领域很经典但嵌入式开发者容易忽略毕竟大家平时处理的是二进制数据哪会想到文本还要转义。第四个坑是供电。我给设备做过一次最简单的长时间稳定性测试用手机充电器5V供电结果运行半小时后设备开始间歇性失联抓包发现是有CRC错误的废包出现。换了实验室稳压电源之后一切正常。这个项目告诉我嵌入式网络设备的电源设计必须留足余量至少要有20%以上的电流余量并且输出端要加足够容量的滤波电容。W5500这类带网络变压器的PHY芯片瞬态电流需求比静态高很多电源响应不够快就掉包。最后分享一个再实用不过的经验遇到界面卡住先别改代码开浏览器F12看Network面板的请求状态十有八九能一步定位问题。HTTP请求是明文的什么时候发出去、什么时候收到响应、响应是什么状态码都清清楚楚写在浏览器里。搞嵌入式网络开发进度一大半在抓包工具里剩下的才是单片机代码的问题。