企业官网建设流程全解析

1. 整体设计思路：为什么F407要配lwIP和HTTPD

把STM32F407和lwIP放到一起，早在立项的时候就已经想清楚了：要做的不是一个单纯跑TCP/IP回环测试的demo，而是一个真正能被业务方拿去用的嵌入式网络节点。F407这颗芯片自带MAC，外挂一个PHY芯片就能把网络接口跑起来，在M4核的芯片里属于性价比非常合适的选型。更重要的是，lwIP作为轻量级TCP/IP协议栈，在嵌入式圈子里沉淀了很多年，API稳定、资料多、踩坑记录也充分，用它来做应用层的承载，比我自己从零写一个协议栈要靠谱得多。

但这里要先扯一句题外话。很多新手拿到F407+lwIP的组合，第一反应是“跑通一个ping就行”。这个目标其实太低了，ping通只代表ICMP和ARP工作正常，离“能干活”还差十万八千里。我这次的目标很明确：在lwIP之上把HTTPD服务器搭起来，让设备能通过浏览器直接访问配置页面、查看运行状态，甚至远程下发控制指令。这样一来，设备就不再是一个只能靠串口或者调试器交互的黑盒子，而是变成了一个拥有标准Web接口的网络终端，这在项目交付和现场调试时价值非常大。

为什么强调HTTPD而不是继续用串口或者自定义TCP协议？原因其实很现实。现场工程师不一定熟悉你的私有协议，更不可能随身带着串口工具，但几乎任何一台笔记本电脑都有浏览器。只要设备接上网线、拿到IP，打开网页就能看到设备状态、修改参数，这个体验和开发效率的提升是质的飞跃。HTTPD是lwIP contrib里自带的轻量级Web服务器实现，资源占用小、接口简单，特别适合直接拿来改造成自己的配置管理界面。

这篇博文是系列的第二篇，上一篇已经解决了RTOS的移植和基础工程搭建，所以这一篇直接基于已有工程继续做网络功能的接入，重点会放在：如何在STM32CubeMX里完成ETH和lwIP的初始化配置，如何把HTTPD服务器跑起来，以及我在实际调试中碰到的问题和排查思路。

整个项目的基本盘是这样：主控是STM32F407ZGT6，PHY芯片用的是LAN8720A，通过RMII接口和主控连接，操作系统用FreeRTOS，lwIP跑在FreeRTOS之上，HTTPD作为应用层任务单独创建。这套组合在市面上能找到大量参考，也是目前F407网络应用的主流方案。

2. 移植之前必须想明白的几个问题

2.1 协议栈选型：lwIP这么多版本，到底该用哪个

lwIP的发展历史比较长，版本也很多。当前在STM32CubeMX里集成的lwIP版本是2.x系列，和早期1.4.1版本相比，API和内存管理方式都有不小的变化。如果你在网上搜索资料，很容易搜到大量基于1.4.1或者老版本2.0.3的代码，直接搬运到新工程里常常会报一堆类型错误或者宏定义找不到的问题。

我的建议是：能用CubeMX生成的版本，就不要自己手动去移植第三方源码。STM32CubeMX会帮你处理掉绝大部分的移植适配工作，包括头文件路径、编译器选项、系统时钟配置等，你只需要关注应用层的逻辑。手动移植lwIP到F407虽然能加深理解，但耗时太长，而且很容易在细节上出错，尤其对于项目周期紧的情况来说完全不划算。

那是不是意味着不需要了解lwIP的内部机制？也不是。至少这几个概念必须在移植前搞清楚：

• netconn API和socket API的区别：HTTPD服务器基于netconn API实现，这是一个偏底层的顺序API，相比socket API更节省资源，但编程模型需要自己处理连接状态。
• 内存管理方式：lwIP支持内存池（POOL）和内存堆（HEAP）两种分配方式，HTTPD这种需要频繁收发数据的场景，对PBUF的配置非常敏感。
• 协议栈线程模型：lwIP + FreeRTOS的常见组合是“tcpip_thread + 应用线程”模型，所有TCP/IP处理都集中在tcpip_thread里，应用线程通过API和它通信。

2.2 硬件接口选型：RMII和MII的抉择

STM32F407内置了以太网MAC，支持MII和RMII两种接口模式。我的板子上用的是RMII，因为只用了7根信号线（除了时钟和地），相比MII的16根信号线大大节省了IO资源。代价是RMII需要外部提供50MHz的参考时钟，这个时钟可以由MCU的MCO引脚输出，也可以由PHY芯片自身产生。

LAN8720A这颗PHY的配置比较简单，但有一个地方特别容易踩坑：它的地址配置引脚（RXER/PHYAD0）决定了PHY的I2C地址。如果这个引脚悬空或者拉高，PHY地址是0，如果拉低是1。我在CubeMX里配置ETH的PHY地址时，必须和硬件实际接法保持一致，否则MDIO读写会失败，直接导致PHY初始化不过。这个我在第一章编译链接时吃过亏，后来用示波器量MDIO波形才发现是PHY地址不匹配的问题。

另外一个重要细节是LAN8720A的复位引脚。很多国产板子为了省事，会把PHY的复位引脚直接接到MCU的复位电路上，也就是说MCU复位时PHY也跟着复位。看起来没问题，但实际调试时你会发现：MCU的以太网MAC初始化在复位释放后可能比PHY更早完成，导致MDIO访问时PHY还没准备好。解决办法是在初始化代码里对PHY做一次软复位，或者硬件上用一个独立GPIO控制PHY复位，程序里先拉低再拉高，延时等待PHY启动完成。

2.3 为什么选择CubeMX生成基础代码

可能有人会问：直接参考正点原子或者野火的lwIP例程，把代码拷过来改改不就行了？确实可以，但我不推荐。原因有三点：

第一，开发板的例程往往针对特定硬件平台，比如特定的PHY芯片、特定的GPIO分配，搬到自己的板子上要改很多地方，改着改着就容易出问题。第二，例程为了教学的完整性，代码量通常很大，很多宏定义和配置项你可能根本用不上，反而增加了阅读负担。第三，CubeMX生成的基础代码和HAL库版本是配套的，不会出现HAL库版本不匹配导致的编译错误。

所以我最终选择的方式是：CubeMX生成底层初始化代码，应用层自己写。CubeMX负责ETH GPIO配置、MAC初始化、DMA描述符配置、lwIP的移植适配层这些工作，我只需要在生成代码的基础上添加HTTPD服务器任务。

3. STM32CubeMX配置实操记录

3.1 时钟树与ETH外设的初始化

在CubeMX里，F407的ETH外设配置其实不复杂，但有几个地方必须细心。首先是时钟树，ETH的时钟来源于系统时钟经过分频后得到，RMII模式要求50MHz的参考时钟必须准确，如果时钟不对，PHY虽然能初始化成功，但数据收发会出现随机丢包，而且这种故障非常难查。

我的配置如下：外部晶振25MHz，PLL倍频到168MHz作为系统主频，ETH的PLL分频输出50MHz时钟，通过MCO2引脚输出给PHY。在CubeMX的Clock Configuration页面里，要确保ETH的时钟源是“PLLCLK”且频率为50MHz，这个数值不对的话，CubeMX会报错提示。

ETH外设的具体配置项这样设置：

• PHY Address：根据硬件实际接法填0或1，我的板子是0。
• MAC Address：随意填一个符合规范的地址，注意不要和局域网内其他设备冲突。我习惯用02:00:11:22:33:44这种本地管理地址格式。
• PHY Clock：选择Divided by 4或根据实际配置选择，这个参数在较新的CubeMX版本里可能自动计算，不用手动管。
• MAC Filter：关闭所有过滤选项，保证能接收到所有数据包，后续调试更方便。

3.2 关键配置项逐个说明

CubeMX的Middleware and Software Packs里勾选lwIP之后，会弹出一大堆配置项。对于一个工程来说，里面每个参数都值得看一遍，但真正需要改的并不多，大部分保持默认即可。我根据自己的实践，整理了一份常用的配置说明：

3.3 生成代码后的必要调整

CubeMX生成代码之后，不能立刻编译下载，有几个地方需要手动调整。首先是lwipopt.h文件，这个文件是CubeMX根据图形化配置生成的，但如果需要更细粒度的控制，可以手动修改其中的宏定义。例如HTTPS的支持、多页面支持、CGI支持等，都需要在lwipopts.h或lwipopt.h里额外开启。

其次是ethernetif.c文件。这个文件是lwIP和STM32 ETH HAL库之间的适配层，正常情况不需要修改。但如果你的PHY芯片比较特殊，比如需要额外的初始化序列，或者地址不是默认值，就需要在这个文件里做微调。

还有一个容易忽略的地方是FreeRTOS的heap大小。lwIP在运行时需要为PCB（Protocol Control Block）分配内存，而lwIP的PCB结构体比较大，如果FreeRTOS的heap不够用，tcp_new()会返回NULL，HTTPD服务器无法启动。我一般把FreeRTOS的heap大小设置为15KB到20KB，这样给lwIP留出足够的余量。

4. 代码逻辑分块：HTTPD服务器怎么真正跑起来

4.1 HTTPD在lwIP中的位置

lwIP的HTTPD不是一个独立的程序，它是一组C文件，被编译进协议栈后作为一个服务运行。换句话说，HTTPD不是一个单独的任务或进程，而是一组可以被其他任务调用的函数。在带操作系统的环境下，HTTPD运行在tcpip_thread线程的上下文里，应用层只需要打开HTTPD的监听端口，剩下的事情由协议栈自动处理。

这带来的一个好处是：应用层不需要为HTTPD单独建任务，节省了一个线程的栈空间。但带来的问题是：HTTPD和业务逻辑的交互方式只有两种——CGI和SSI。CGI用于动态生成内容或处理表单提交，SSI用于在HTML模板中插入动态数据。这两种机制是HTTPD的核心，必须有清晰的理解才能高效使用。

4.2 把HTTPD文件加入工程

CubeMX默认不会自动把HTTPD的源码加入工程，需要在Middleware的lwIP配置里打开“LWIP_HTTPD”选项，这样CubeMX会把httpd.c、fs.c、fsdata.c等文件生成到工程目录中。但要注意：如果使用自定义文件系统（比如将网页文件存到外部Flash），需要修改fs.c的读取接口。这一点我后面会专门讲。

生成后的文件路径一般在Middlewares/Third_Party/LwIP/src/apps/httpd/目录下。如果你用的CubeMX版本较新，这个目录下还会有一个httpd_structs.h头文件，里面定义了HTTPD的默认响应头、错误页面等。如果要做个性化的错误页面，可以在配置宏里关闭默认定义，替换成自定义数据。

4.3 实现CGI与SSI的示例代码

CGI和SSI的实现，本质上就是在C代码里注册回调函数，当HTTPD解析到特定URL或者特定标记时，调用对应的处理函数。

下面是一个简易的CGI实现示例，用于处理设备发送的控制指令：

#include "lwip/apps/httpd.h" static const char *cgi_device_handler(int iIndex, int iNumParams, char *pcParam[], char *pcValue[]) { if (iNumParams > 0) { if (strcmp(pcParam[0], "led") == 0) { set_led_state(pcValue[0][0] == '1'); } else if (strcmp(pcParam[0], "fan") == 0) { set_fan_state(pcValue[0][0] == '1'); } } return "/index.shtml"; } static const tCGI cgi_handlers[] = { { "/device.cgi", cgi_device_handler }, }; void httpd_cgi_init(void) { http_set_cgi_handlers(cgi_handlers, 1); }

这个处理函数的作用是：当浏览器访问/device.cgi?led=1&fan=0时，HTTPD会解析URL中的参数，调用cgi_device_handler，把LED打开、风扇关闭，然后返回一个重定向页面。注意tCGI结构体中的URI字符串必须和浏览器中的路径完全匹配，不然HTTPD不会调用你的处理函数。

SSI的实现思路类似，但用法不同。SSI的作用是在HTML页面里嵌入动态数据，比如当前温度、设备运行时间等。在网页HTML代码中写入类似这样的标记：

<p>当前温度：<!--#echo temperature --></p>

然后在C代码中注册SSI标记处理器：

static u16_t ssi_temperature_handler(int iIndex, char *pcInsert, int iInsertLen) { u16_t len = 0; char temp_str[8]; snprintf(temp_str, sizeof(temp_str), "%.1f", get_temperature()); len = strlen(temp_str); if (iInsertLen >= len) { MEMCPY(pcInsert, temp_str, len); } return len; } static const tSSIHandler ssi_handlers[] = { { "temperature", ssi_temperature_handler }, }; void httpd_ssi_init(void) { http_set_ssi_handler(ssi_handlers, 1); }

注意SSI标记的处理函数签名是固定的，函数名temperature对应页面里<!--#echo temperature -->中的temperature字段。HTTPD在发送页面时，会扫描页面内容，碰到匹配的标记就会调用对应函数，将返回的字符串动态插入页面。这样用户打开网页时看到的就是实时数据，而不是静态的HTML文件。

4.4 FS镜像的生成方式

HTTPD的网页文件默认是编译到固件里的，需要先转换成一个C文件（即FS镜像）。lwIP源码里提供了一个makefsdata工具，用于把HTML、CSS、JS等文件打包成一个C语言数组。

我的做法是：创建一个fs目录，放入需要的网页文件（比如index.html、style.css、app.js），然后在命令行执行makefsdata，它会生成一个fsdata.c文件，里面是一个大的static const unsigned char数组。把这个文件加入工程编译即可。

需要留意的是，makefsdata的版本必须和你的lwIP版本匹配。我用的是lwIP 2.1.2版本的tools目录下的工具，如果版本不匹配，生成的fsdata.c可能无法编译通过，或者HTTPD在运行时报错。

每次修改网页文件之后，都要重新执行一次makefsdata并重新编译固件。这个过程比较繁琐，但好处是网页文件被打包进固件，不存在外部存储的依赖问题。

5. HTTPD与业务代码的对接逻辑

5.1 数据流梳理：从浏览器到MCU再到外设

完整的HTTPD应用场景，数据流大概是这样：

浏览器发起HTTP请求到F407的IP地址 → lwIP协议栈解析HTTP头 → HTTPD匹配URL路由 → 调用对应的CGI处理器或SSI处理器 → CGI/SSI函数访问业务层代码（比如读取传感器数值、控制继电器） → 返回结果给HTTPD → HTTPD封装成HTTP响应 → 协议栈把数据通过网卡发送出去 → 浏览器显示结果。

理解这条链路非常重要，因为它决定了代码的分层结构。业务代码和HTTPD之间应该通过函数接口隔离，而不是直接混在一起。我在写这个项目的时候，专门封装了一个device_api.c，把所有对硬件的操作收敛到这几个接口里：

• int device_get_temperature(float *temp)
• int device_set_led(int state)
• int device_get_status(char *buf, int len)

这样一来，CGI和SSI处理器只需要调用这些接口，不需要关心底层是GPIO操作还是I2C读取，代码的可维护性和可测试性都大大提升。

5.2 初始化顺序的坑

如果HTTPD要在RTOS环境下工作，初始化顺序是很讲究的。我的推荐顺序是：

1. 首先确保ETH和PHY已经完成初始化，MX_LWIP_Init()被调用，协议栈已经运行。
2. 确保网络链路ready，这个可以通过netif_is_up()判断。
3. 调用httpd_init()启动HTTPD监听。
4. 注册业务层的CGI和SSI处理器。

这里特别要注意的是：httpd_init()必须在lwIP初始化之后调用，这一点在文档里有说明，但实际中很多人会顺手把它放在main函数的任意位置，导致HTTPD启动失败。我当时排查了一个多小时，加日志才发现HTTPD的TCP PC B还没有创建成功，因为lwIP根本没有启动。

5.3 调试利器：HTTPD自带的cgi/ssi日志开关

lwIP的HTTPD代码里预置了一些调试宏，用LWIP_DEBUG全局开关控制。在lwipopts.h里，可以把HTTPD_DEBUG设置为LWIP_DBG_ON，这样HTTPD会在串口输出每一个HTTP请求的详细信息，包括URL、参数、返回状态码等。

这个功能对调试来说非常有用。我在调CGI的时候，发现某个请求始终返回404，打开HTTPD_DEBUG之后，很快发现是URL中的路径大小写不匹配。这种问题光靠看代码很难发现，但通过日志一眼就能定位。

5.4 多任务环境下HTTPD线程栈的动态分配

FreeRTOS环境下，HTTPD本身不单独占线程，但它的回调函数是运行在tcpip_thread上下文中的。因此，tcpip_thread的栈大小直接影响HTTPD的稳定性。我刚开始把TCPIP_THREAD_STACKSIZE设置为默认的1024字节，结果每次访问CGI页面都会导致系统崩溃。

排查过程是这样的：崩溃发生的位置每次都在fs_open函数里，初步怀疑是FS文件系统的问题，后来发现其实就是栈溢出。CGI处理函数里面调用了业务接口，业务接口又调用了sprintf等库函数，栈消耗远超预期。我把TCPIP_THREAD_STACKSIZE从1024改到2048，问题立刻消失。

这个现象提醒我一件事：嵌入式网络应用的栈大小不能照抄默认值，必须结合自己的业务逻辑做预估，必要时用FreeRTOS的任务栈统计功能（uxTaskGetStackHighWaterMark）来实测。

6. 调试实录：我踩过的三个坑

6.1 HTTPD启动编译失败：找不到httpd_init函数

现象：编译时报undefined reference to 'httpd_init'，但代码里明明调用了这个函数。

原因：CubeMX在生成代码时，如果LWIP_HTTPD这个宏没有打开，httpd.c文件根本不会被编译进工程，导致链接失败。但由于CubeMX版本差异，LWIP_HTTPD宏和LWIP_HTTPD_SUPPORT宏可能同时存在，需要把相关的宏都检查一遍。

解决办法：打开CubeMX的lwIP配置界面，在“HTTPD”一栏确认LWIP_HTTPD为Enabled。如果已经打开但仍然报错，检查一下工程文件里是否真的包含了httpd.c源文件，有些时候CubeMX生成的工程不会自动把新的中间件文件加入编译列表，需要手动添加。

6.2 浏览器敲IP后一直转圈，但能ping通

现象：ping能通，TCP也能拉起连接，但浏览器访问不了，一直处于加载中状态。

排查过程：先用curl http://192.168.1.10/index.html测试，返回200 OK，但内容长度和实际文件大小对不上。再打开HTTPD_DEBUG日志，发现HTTPD发送完HTTP头之后，数据传输到一半就停止了。

最终定位：问题出在FS文件系统的读取方式上。HTTPD在发送大文件时，会分多次调用FS读取函数。如果FS读取函数返回的数据长度在最后一次调用时没有正确处理，HTTPD就会认为数据传输完毕，提前结束连接。

解决办法：重新生成fsdata.c文件，并确认FS读取逻辑正确实现了“文件结尾返回0”的约定。我在makefsdata时用了旧版本工具，生成的fsdata.c格式和当前lwIP版本不兼容，换成正确版本后问题消失。

6.3 访问页面后开发板死机或进入HardFault

现象：开发板在访问页面后随机出现HardFault，偶尔能正常访问，但多刷新几次必死。

排查过程：用调试器查看HardFault时的调用栈，发现地址落在memp_free函数附近，推测是内存管理出了问题。进一步排查，发现lwIP的MEM_SIZE被我设置得太小，TCP传输窗口稍大就导致内存不足。

解决办法：把MEM_SIZE从1024增加到2048，同时把TCP_SND_BUF和TCP_WND调整为符合实际需求的数值。另外，检查FreeRTOS的heap是否有足够的碎块率，可以开启configUSE_MALLOC_FAILED_HOOK来跟踪内存分配失败的情况。

7. HTTPD页面设计与体验优化

7.1 页面风格：低依赖优先

嵌入式设备的Web页面有几个天然限制：存储空间有限、MCU的HTTPD并发处理能力弱、网络带宽可能不稳定。因此，页面的设计原则应该是低依赖、小体积、少请求。

我的做法是：单页面应用，HTML+CSS+JS全部内联在一起，不额外加载外部文件。实测一个自刷新状态页加上两个控制按钮，体积压缩在8KB以内。这样HTTPD在单连接模式下也能流畅处理。如果你需要更复杂的页面，建议尽量精简CSS框架，别把动辄几百KB的Bootstrap塞进MCU。

7.2 动态刷新的实现方式

嵌入式设备的状态页通常需要实时更新数据，比如温度、电压、运行时长。这里有两种常见实现方式。

第一种是HTML Meta Refresh，在页面头部加一行：

<meta http-equiv="refresh" content="5">

浏览器每5秒自动刷新一次页面。这种方式最简单，但会导致整页刷新，感官上会有闪烁，而且每次刷新都会重新拉取所有资源。

第二种是AJAX轮询，页面通过JavaScript定时向后端发起AJAX请求，然后只更新页面上的局部区域。这种方式体验更好，但对HTTPD的并发处理能力有一定的要求。好在lwIP的HTTPD支持多连接，只要配置好LWIP_HTTPD_SUPPORT相关宏，并稍微调大内存，就能承受住几路AJAX轮询。

我实际使用的是第二种。核心代码大概长这样：

function refreshStatus() { fetch('/device_status.cgi') .then(response => response.json()) .then(data => { document.getElementById('temp').innerText = data.temperature; document.getElementById('voltage').innerText = data.voltage; }); } setInterval(refreshStatus, 2000);

配合的CGI处理器在返回时，把JSON数据作为字符串返回，HTTPD会自动加上正确的Content-Type。注意如果CGI返回的JSON里有中文，需要在HTTPD配置里打开相关字符集支持。

7.3 安全性考虑的配合

嵌入式设备的Web服务器通常跑在局域网内，安全要求不像公网那么高，但也有一些基本问题值得注意。比如CGI接口不能接受未经过滤的参数，如果参数中包含超长字符串或者特殊字符，可能会引发缓冲区溢出。我的做法是所有进入业务层的参数都做长度校验和黑白名单过滤，不做任何假设。

另外，如果设备会暴露到公网，建议至少在HTTPD前面加一层简单的账号密码验证。lwIP的HTTPD默认不支持Basic Auth，但你可以通过CGI判断Authorization头来实现一个简单的登录逻辑。这个改造不算复杂，但能挡掉绝大多数搜索引擎扫描器的低级尝试。

8. 性能验证与后续优化方向

8.1 基础功能验证清单

当你按照上面的步骤做完，验证的时候可以按这个清单逐项检查：

• PC能ping通板子的IP，丢包率0%。
• 浏览器能打开默认首页，内容显示正确。
• CGII接口（如设备控制）能正确执行并返回结果。
• SSI动态数据随业务逻辑变化，刷新页面能看到更新。
• 长时间运行（24小时以上）后，内存无持续增长趋势，页面仍能正常访问。
• 断电重启后设备能自动恢复网络功能，无需手动操作。

我这个项目做到最后，使用Stress工具模拟多客户端同时访问设备页面，20路连接同时打开的情况下，HTTPD响应依然正常，偶尔出现一次五次重传但能自行恢复。

8.2 后续可以扩展的方向

HTTPD跑通之后，整个网络栈的架子就已经立住了。后续扩展的可能性很多。

如果后续需要更复杂的交互协议，可以在lwIP之上叠加一个自定义的JSON-RPC层，让HTTPD只负责静态页面和动态状态的展示，而真正的控制指令走WebSocket或者MQTT。F407的剩余资源完全够用。

另外，针对数据采集场景，可以考虑把FS镜像放到外部SPI Flash上，用LittleFS或SPIFFS管理，这样网页升级不需要重新刷固件。我在另一个项目里用W25Q128做过这个方案，换页面只需要通过HTTP上传一个新的FS镜像，开发效率提升明显。

8.3 项目文件的整理归档

项目做完之后，一定要把CubeMX的.ioc文件和lwIP的配置导出发给团队共享，这样其他人拿到的是一模一样的初始工程，不会因为某个宏定义不一致导致行为差异。这一点在团队协作时尤其重要，我见过太多“在我电脑上是好的”这种问题，最后查下来都是配置文件不一致导致的。

正文完结

从CubeMX的基础配置到HTTPD服务器在F407上完整运行，中间要过的坎比预想中多，但每一个坑趟完之后，对lwIP和TCP/IP协议栈的理解都会加深一截。这套“lwIP + HTTPD”的组合，几乎可以覆盖所有需要设备被外部访问和控制的场景，往小了说是给嵌入式设备开了个网页后台，往大了说就是设备真正具备了联网服务的雏形。

我个人在实际调试中最深的体会是：跑通协议栈只是开始，协议栈上的应用设计才是决定项目是否好用、是否稳定的关键。多花点时间想清楚HTTPD的CGI/SSI划分、内存开销和页面交互逻辑，能让你在后续开发和现场维护时省下无数精力。尤其是内存问题，宁可一开始给lwIP留足余量，也不要在硬件定型后再来抠内存，那个阶段的改动成本远比现在高得多。

最后再分享一个小技巧：如果你在做嵌入式Web应用，建议把浏览器的开发者工具打开，看Network面板里的请求耗时和响应体大小。这个习惯能帮你快速定位到是网络问题、HTTPD问题还是页面本身的问题，省下不少对着串口日志空想的时间。