1. ESP32 WiFi联网基础：从模式理解到工程实现

在嵌入式物联网系统中，网络连接是数据采集、远程控制与云平台交互的基石。ESP32系列芯片因其集成度高、协议栈成熟、开发生态完善，成为WiFi联网方案的主流选择。但初学者常陷入一个认知误区：将WiFi配置简单等同于“填入SSID和密码”。实际上，ESP32的WiFi子系统是一个具备完整状态机、多模式支持、IP协议栈管理能力的复杂模块。本节将剥离教学视频中的口语化表达，以工程师视角系统梳理ESP32 WiFi联网的核心逻辑、配置原理与工程实践路径，重点解析AP与STA两种基础工作模式的本质差异及其在真实项目中的选型依据。

1.1 四种WiFi工作模式的技术内涵与适用场景

ESP32的WiFi驱动层定义了四种标准工作模式，其命名直接对应IEEE 802.11协议栈中的角色定义：

• WIFI_MODE_NULL ：空闲模式。此模式下WiFi射频前端完全关闭，MAC层停止所有帧收发，功耗最低。适用于设备进入深度休眠前的资源释放阶段，或系统初始化完成前的待机状态。
• WIFI_MODE_STA （Station Mode）：客户端模式。ESP32作为网络终端，主动扫描、认证并关联至外部接入点（如家用路由器、手机热点）。该模式是绝大多数物联网终端设备的默认选择，承担着数据上行（向云平台发送传感器数据）与下行（接收控制指令）的核心任务。
• WIFI_MODE_AP （Access Point Mode）：接入点模式。ESP32自身扮演无线路由器角色，广播SSID，管理客户端接入，分配IP地址，并处理内部网络流量。此模式常见于设备配网引导、本地调试服务、离线控制面板等场景。
• WIFI_MODE_APSTA ：混合模式。ESP32同时启用STA与AP功能，形成一个“桥接”节点：一方面作为客户端连接至上级网络（如互联网），另一方面作为AP为本地设备提供接入服务。该模式对内存与CPU资源消耗显著增加，需谨慎评估系统负载。

理解AP与STA的本质，关键在于把握其在网络拓扑中的角色定位。AP（Access Point）是网络基础设施，负责建立无线信道、管理BSS（基本服务集）、处理关联/认证/加密等链路层协议；而STA（Station）是网络终端，仅需遵循AP发布的参数进行同步与通信。类比现实世界，AP相当于小区物业提供的公共WiFi路由器，STA则是住户手机——手机不会去配置小区的主干网，它只关心如何连上物业的热点。因此，在设计阶段必须明确：你的设备是“提供网络服务”（AP），还是“使用网络服务”（STA），抑或二者兼有（APSTA）。错误的模式选择将导致后续IP配置、路由策略、安全机制全部失效。

1.2 网络参数配置：IP地址、子网掩码与网关的工程意义

无论AP或STA模式，IP层配置都是网络可达性的前提。字幕中提及的 ip 、 gateway 、 subnet_mask 三项参数，绝非简单的字符串赋值，而是直接决定了TCP/IP协议栈的行为逻辑与网络互通能力。

• IP地址（ip） ：设备在网络中的唯一标识。在STA模式下，若配置为 INADDR_ANY （即 0.0.0.0 ），则由DHCP服务器动态分配；若指定静态IP（如 192.168.43.152 ），则必须确保该地址未被网络中其他设备占用，且位于目标路由器的DHCP地址池范围之外，否则将引发IP冲突。在AP模式下，IP地址即为AP自身的管理地址，也是DHCP服务器的起始地址（如 192.168.4.1 ），所有关联的STA设备将从此地址开始获取IP。
• 子网掩码（subnet_mask） ：用于划分网络地址与主机地址。 255.255.255.0 （/24）是最常见的C类子网掩码，表示前24位为网络号，后8位为主机号。其工程意义在于：当ESP32需要向某IP发送数据时，会先将该IP与自身子网掩码进行按位与运算，再与自身网络地址比较。若结果一致，则判定目标在同一局域网内，直接通过ARP广播获取MAC地址；若不一致，则必须将数据包转发给网关。因此，子网掩码错误会导致设备无法正确识别“本地通信”与“跨网通信”，造成连接失败或路由黑洞。
• 网关（gateway） ：数据包离开本地网络的出口。在STA模式下，网关即为上级路由器的LAN口IP（如 192.168.43.1 ），所有发往互联网的数据均需经此地址转发。在AP模式下，由于AP自身即为局域网的中心节点，其网关通常指向自身（ 192.168.4.1 ），因为AP内部已集成NAT与路由功能，无需额外网关即可处理内外网流量。

一个典型误区是认为AP模式下的网关可随意设置。事实上，当ESP32运行AP模式时，其内置的 esp_netif 组件会自动创建一个名为 ap0 的网络接口，并为其绑定 192.168.4.1/24 的默认IP与子网。若手动将网关设为其他地址（如 192.168.1.1 ），而该地址并不属于 ap0 接口的子网，则会导致DHCP分配的客户端无法访问AP的Web服务，因为客户端的路由表中不存在通往 192.168.4.1 的有效路径。因此，AP模式下的 ip 、 subnet_mask 、 gateway 三者必须构成一个自洽的子网定义。

1.3 配置结构体的设计哲学：解耦与可维护性

字幕中提到“已将网络参数打包成一个struct”，这并非简单的代码组织，而是嵌入式软件工程中至关重要的解耦实践。一个典型的 wifi_config_t 结构体定义如下：

typedef struct {
    ip4_addr_t ip;           // AP/STA的IPv4地址
    ip4_addr_t gateway;      // 默认网关地址
    ip4_addr_t subnet_mask;  // 子网掩码
    char ssid[32];           // WiFi网络名称
    char password[64];       // WiFi密码
    wifi_mode_t mode;        // 工作模式：WIFI_MODE_STA / WIFI_MODE_AP
} wifi_config_t;

此设计蕴含三层工程价值：
1. 职责分离 ：网络层参数（IP、网关、掩码）与链路层参数（SSID、密码、模式）物理隔离，避免因修改WiFi密码而意外影响IP配置。
2. 模式无关性 ：同一结构体可服务于AP与STA两种模式。在STA模式下， ip 、 gateway 、 subnet_mask 字段可设为 0.0.0.0 ，由DHCP自动填充；在AP模式下，三者则承载确定的静态值。这种灵活性使上层业务逻辑无需感知底层模式切换细节。
3. 可扩展性 ：当项目需求演进（如需支持WPA3加密、802.11r快速漫游、静态DNS服务器），只需在结构体中新增字段，而核心初始化函数签名保持不变，极大降低维护成本。

实践中，应避免将配置硬编码于初始化函数内部。正确的做法是定义全局配置实例，并在编译期或运行期注入：

// settings.h
extern const wifi_config_t wifi_ap_config;
extern const wifi_config_t wifi_sta_config;

// settings.c
const wifi_config_t wifi_ap_config = {
    .ip = IP4_ADDR(192, 168, 4, 1),
    .gateway = IP4_ADDR(192, 168, 4, 1),
    .subnet_mask = IP4_ADDR(255, 255, 255, 0),
    .ssid = "ESP32Web",
    .password = "12345678",
    .mode = WIFI_MODE_AP
};

const wifi_config_t wifi_sta_config = {
    .ip = IP4_ADDR(0, 0, 0, 0), // DHCP
    .gateway = IP4_ADDR(0, 0, 0, 0),
    .subnet_mask = IP4_ADDR(0, 0, 0, 0),
    .ssid = "Mobile",
    .password = "your_password",
    .mode = WIFI_MODE_STA
};

这种声明式配置方式，使硬件适配、客户定制、A/B测试等场景变得极为简单——仅需替换 settings.c 文件，无需修改任何驱动或业务逻辑代码。

2. AP模式工程实现：从射频启动到Web服务就绪

AP模式是ESP32作为独立网络节点的起点，其配置流程严格遵循“物理层→链路层→网络层→应用层”的递进逻辑。字幕中演示的 setAP() 函数，实则是对ESP-IDF官方API的一次封装调用，其背后是完整的硬件抽象与协议栈初始化序列。

2.1 射频与MAC层初始化： esp_wifi_set_mode() 与 esp_wifi_start()

所有WiFi操作始于对射频硬件的控制。 esp_wifi_set_mode(WIFI_MODE_AP) 并非简单设置一个寄存器，而是触发了一系列底层动作：
- 配置WiFi基带芯片（如ESP32-S3内置的RF模块）进入AP专用工作状态，启用Beacon帧定时器与探针响应逻辑；
- 初始化MAC层状态机，注册AP模式特有的事件回调（如 WIFI_EVENT_AP_STACONNECTED 、 WIFI_EVENT_AP_STADISCONNECTED ）；
- 分配并初始化AP模式所需的内存缓冲区，包括Beacon帧缓存、Probe Response帧缓存、以及关联客户端列表。

此步骤必须在 esp_netif_create_default_wifi_ap() 之后执行，因为 esp_netif 组件负责创建网络接口对象（ esp_netif_t *ap_netif ），而 esp_wifi_set_mode() 需要该对象来绑定网络参数。若顺序颠倒，将导致WiFi驱动无法找到对应的网络接口，初始化失败。

2.2 网络接口绑定： esp_netif_set_ip_info() 与 esp_netif_dhcps_start()

AP模式的IP栈配置分为两步：静态IP绑定与DHCP服务启动。
- esp_netif_set_ip_info(ap_netif, &ip_info) ：将 ip_info 结构体（含IP、网关、掩码）写入 ap_netif 对象的内部数据结构。此操作直接影响 ip4_route_add() 的路由表生成，确保发往 192.168.4.0/24 子网的数据包被导向 ap_netif 。
- esp_netif_dhcps_start(ap_netif) ：启动内置的轻量级DHCP服务器。该服务监听UDP端口67，响应来自关联STA的DHCP Discover请求，并按预设范围（默认 192.168.4.100 至 192.168.4.200 ）分配IP地址、子网掩码、网关及DNS服务器。值得注意的是，DHCP服务器的网关地址即为 ap_netif 的IP（ 192.168.4.1 ），这保证了客户端能正确构建默认路由。

一个易被忽略的关键点是： esp_netif_dhcps_start() 必须在 esp_wifi_start() 之后调用。因为DHCP服务器需要WiFi射频处于活动状态才能接收客户端的广播包。若提前启动DHCP，服务将无法收到任何请求，导致所有关联的STA设备获取不到IP，表现为“连接成功但无法上网”。

2.3 AP参数配置： esp_wifi_set_config() 与安全策略

esp_wifi_set_config() 是AP模式的核心配置函数，其参数 wifi_config_t 结构体包含两个关键子结构：
- wifi_ap_config_t ：定义AP的无线参数，包括 ssid 、 password 、 authmode （认证模式）、 channel （信道）、 max_connection （最大客户端数）等。
- wifi_sta_config_t ：在AP模式下此结构体被忽略，但为结构体统一性而保留。

其中， authmode 的选择直接决定安全性等级：
- WIFI_AUTH_OPEN ：无加密，仅用于调试，生产环境严禁使用；
- WIFI_AUTH_WPA_WPA2_PSK ：WPA/WPA2混合模式，兼容性最好，推荐用于大多数场景；
- WIFI_AUTH_WPA2_PSK ：纯WPA2，安全性更高，但部分老旧设备可能不兼容。

字幕中使用的密码 "12345678" 虽满足WPA2最小长度要求（8位），但在实际项目中必须规避此类弱口令。建议采用AES-256加密的密钥派生算法（如PBKDF2），或集成安全元件（SE）存储密钥，杜绝明文密码硬编码。

2.4 Web服务部署： httpd_start() 与静态页面托管

AP模式的价值在于提供本地服务能力。字幕中演示的 192.168.4.1 网页访问，依赖于ESP-IDF内置的HTTPD组件。其初始化流程如下：

// 创建HTTP服务器实例
httpd_handle_t server = NULL;
httpd_config_t config = HTTPD_DEFAULT_CONFIG();
config.server_port = 80; // 标准HTTP端口
httpd_start(&server, &config);

// 注册URI处理函数
httpd_uri_t index_uri = {
    .uri       = "/",
    .method    = HTTP_GET,
    .handler   = index_handler, // 处理根路径请求
    .user_ctx  = NULL
};
httpd_register_uri_handler(server, &index_uri);

index_handler 函数负责生成HTTP响应。对于静态HTML页面（如 index.html ），最佳实践是将页面内容编译进Flash，而非运行时读取文件系统：

const char index_html[] = "<html><body><h1>Hello ESP32</h1></body></html>";

esp_err_t index_handler(httpd_req_t *req) {
    httpd_resp_set_type(req, "text/html");
    httpd_resp_send(req, index_html, HTTPD_RESP_USE_STRLEN);
    return ESP_OK;
}

此方案避免了SPIFFS或LittleFS文件系统的I/O开销与磨损，提升响应速度与可靠性。当需要动态内容时，可结合 httpd_resp_send_chunk() 分块发送，或使用模板引擎（如 esp_http_server 的 httpd_resp_sendstr_chunked ）。

3. STA模式工程实现：从网络扫描到稳定连接

STA模式是物联网终端的常规工作状态，其挑战在于网络环境的不确定性——信号强度波动、AP列表动态变化、认证失败重试、IP地址租约更新等。字幕中一笔带过的 setSTA() 函数，背后是一套健壮的状态机与事件驱动架构。

3.1 连接状态机： WIFI_EVENT_STA_START 到 IP_EVENT_STA_GOT_IP

ESP-IDF的WiFi连接流程由一系列事件驱动，构成一个清晰的状态转换图：

1. WIFI_EVENT_STA_START ：WiFi驱动启动完成，进入扫描准备状态；
2. WIFI_EVENT_STA_DISCONNECTED ：连接尝试失败或主动断开，触发重连逻辑；
3. IP_EVENT_STA_GOT_IP ：成功获取IP地址，网络层就绪，可启动应用服务；
4. IP_EVENT_STA_LOST_IP ：IP地址丢失（如DHCP租约过期），需重新获取。

关键在于， esp_wifi_connect() 调用后，程序不应阻塞等待连接成功，而应注册事件处理函数，在 IP_EVENT_STA_GOT_IP 事件发生时执行业务逻辑。字幕中在 setup() 中直接调用 WiFi.begin() 并期望立即获得IP，是一种危险的同步假设。正确做法是：

static void wifi_event_handler(void* arg, esp_event_base_t event_base,
                               int32_t event_id, void* event_data) {
    if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_START) {
        esp_wifi_connect(); // 开始连接
    } else if (event_base == WIFI_EVENT && event_id == WIFI_EVENT_STA_DISCONNECTED) {
        esp_wifi_connect(); // 自动重连
    } else if (event_base == IP_EVENT && event_id == IP_EVENT_STA_GOT_IP) {
        ip_event_got_ip_t* event = (ip_event_got_ip_t*) event_data;
        ESP_LOGI(TAG, "Got IP: " IPSTR, IP2STR(&event->ip_info.ip));
        start_application_services(); // 启动MQTT、WebServer等
    }
}

此异步模型确保了系统在连接过程中仍能响应其他任务（如传感器采样），符合FreeRTOS实时性要求。

3.2 扫描与选择策略： esp_wifi_scan_start() 与RSSI阈值

字幕中未提及的 esp_wifi_scan_start() ，是实现智能配网的关键。当设备首次上电或需要切换网络时，应主动扫描周边AP：

wifi_scan_config_t scan_config = {
    .ssid = NULL,         // 扫描所有SSID
    .bssid = NULL,        // 不限定BSSID
    .channel = 0,         // 扫描所有信道
    .show_hidden = true   // 包含隐藏SSID
};
esp_wifi_scan_start(&scan_config, true); // 同步扫描

扫描完成后，通过 esp_wifi_scan_get_ap_num() 与 esp_wifi_scan_get_ap_records() 获取AP列表。此时可实施高级策略：
- 信号强度筛选 ：丢弃RSSI低于-80dBm的AP，避免连接弱信号导致通信不稳定；
- 频段偏好 ：优先选择2.4GHz信道（ESP32-S3仅支持2.4G），避开拥挤的信道1、6、11；
- SSID白名单 ：仅连接预配置的SSID，防止误连恶意AP。

3.3 动态IP管理：DHCP客户端与租约续期

在STA模式下， ip4_addr_t ip 设为 0.0.0.0 即启用DHCP客户端。ESP-IDF的DHCP客户端会自动处理以下事务：
- 发送DHCP Discover广播，寻找可用DHCP服务器；
- 接收DHCP Offer，选择最优IP；
- 发送DHCP Request确认租约；
- 定期发送DHCP Request续期（默认租期24小时，续期时间点为租期50%处）。

开发者需关注 IP_EVENT_STA_LOST_IP 事件，它表明DHCP租约已过期且续期失败。此时应触发一次完整的重连流程： esp_wifi_disconnect() → esp_wifi_connect() ，而非简单重启DHCP客户端。因为网络层状态（如路由表、DNS缓存）可能已损坏，仅重启DHCP无法恢复。

3.4 连接稳定性增强：心跳检测与故障转移

生产环境中，WiFi连接可能因干扰、AP重启、信道切换等原因中断。字幕中演示的“连接成功即万事大吉”是理想化假设。工程实践需加入健康检查：

• TCP Keepalive ：为长连接（如MQTT）启用Keepalive选项，定期发送探测包，及时发现链路断裂；
• Ping探测 ：在应用层定时向网关（ 192.168.43.1 ）或公共DNS（ 8.8.8.8 ）发送ICMP Echo Request，若连续3次超时则判定网络不可达；
• 多SSID支持 ：在 wifi_config_t 中预置多个 wifi_sta_config_t 实例，当首选SSID连接失败时，自动尝试备选SSID。

4. 混合模式（APSTA）的工程权衡与陷阱规避

APSTA模式赋予ESP32“既是客户端又是路由器”的双重身份，看似强大，实则暗藏资源争用与逻辑冲突的风险。字幕中仅提及“AP、STA同时进行”，却未揭示其复杂性。工程师在选用此模式前，必须进行严格的可行性分析。

4.1 资源消耗评估：内存、CPU与射频带宽

ESP32-S3的RAM资源（320KB SRAM + 2MB PSRAM）在APSTA模式下面临严峻挑战：
- 内存占用 ：AP模式需为每个关联STA分配约1.5KB内存（用于TCP/IP栈、加密上下文、缓冲区）；STA模式需为WiFi驱动、协议栈、DHCP客户端预留约20KB。当AP侧有5个客户端时，仅网络栈内存就超过100KB，极易触发 heap_caps_malloc() 失败。
- CPU负载 ：AP模式需持续生成Beacon帧（每100ms一次），处理Probe Request/Response；STA模式需维持与上级AP的关联、处理数据帧、执行PS轮询。双任务并发将使CPU占用率长期高于70%，影响其他任务（如ADC采样、PWM输出）的实时性。
- 射频冲突 ：AP与STA共享同一套射频前端与MAC层。当AP正在发送Beacon帧时，STA无法接收来自上级AP的数据；反之亦然。这导致吞吐量下降约30%-40%，且增加丢包率。

因此，APSTA模式仅适用于低带宽、低并发的特定场景，如：设备配网期间，AP提供配网界面，STA同步连接云平台进行固件校验；或工业现场，AP为本地HMI提供服务，STA向SCADA系统上报数据。对于高吞吐需求（如视频流传输），应坚决避免。

4.2 网络隔离与路由策略：避免环路与冲突

APSTA模式下存在两个独立的网络接口： sta_netif （连接上级网络）与 ap_netif （提供本地服务）。若不加隔离，将引发严重问题：
- 路由环路 ：若 sta_netif 与 ap_netif 配置在同一子网（如均为 192.168.4.0/24 ），Linux内核会随机选择路由，导致数据包在两个接口间无限循环；
- IP地址冲突 ： sta_netif 从上级DHCP获取的IP可能与 ap_netif 的静态IP（ 192.168.4.1 ）冲突；
- NAT穿透失败 ：当 ap_netif 的客户端尝试访问 sta_netif 的公网服务时，若未正确配置SNAT/DNAT规则，连接将被拒绝。

解决方案是强制网络隔离：
- 为 ap_netif 分配独立子网（如 192.168.100.0/24 ），与 sta_netif 的子网（如 192.168.43.0/24 ）完全分离；
- 在 sta_netif 上启用 esp_netif_create_default_wifi_sta() 时，禁用其DHCP客户端，改用静态IP或由上级网络分配；
- 如需 ap_netif 客户端访问互联网，必须在 sta_netif 上启用NAT转发（ esp_netif_action_start_nat() ），并将 ap_netif 的默认路由指向 sta_netif 的IP。

4.3 事件处理的复杂性：双接口事件流管理

APSTA模式下，事件总线将同时抛出STA与AP两类事件，开发者必须精确区分来源：

void wifi_event_handler(void* arg, esp_event_base_t event_base,
                        int32_t event_id, void* event_data) {
    if (event_base == WIFI_EVENT) {
        switch(event_id) {
            case WIFI_EVENT_STA_START:
                // 处理STA启动
                break;
            case WIFI_EVENT_AP_START:
                // 处理AP启动
                break;
            case WIFI_EVENT_STA_CONNECTED:
                // STA连接成功
                break;
            case WIFI_EVENT_AP_STACONNECTED:
                // AP有新客户端接入
                break;
        }
    } else if (event_base == IP_EVENT) {
        if (event_id == IP_EVENT_STA_GOT_IP) {
            // STA获取IP
        } else if (event_id == IP_EVENT_AP_STAIPASSIGNED) {
            // AP为客户端分配IP
        }
    }
}

混淆 WIFI_EVENT_STA_CONNECTED 与 WIFI_EVENT_AP_STACONNECTED 将导致逻辑错误。前者表示ESP32自身已连接至上级网络，后者表示有外部设备连接至ESP32的AP。二者在业务逻辑中代表完全不同的状态，必须严格区分。

5. 实战调试技巧与常见故障排查

理论配置正确，不代表运行必然成功。WiFi调试是嵌入式开发中最耗时的环节之一。以下是基于多年实战总结的高效排查路径。

5.1 日志分级与关键信息捕获

启用ESP-IDF的详细日志是诊断的第一步。在 menuconfig 中设置：
- Component config → Log output → Default log verbosity → DEBUG
- Component config → WiFi → WiFi debug log option → All

重点关注以下日志片段：
- [WiFi] wifi_init_config(): system heap: xxxxxx ：确认内存充足；
- [WiFi] wifi_set_channel(): channel=6 ：验证信道配置生效；
- [WiFi] wifi_set_config(): ssid=ESP32Web, authmode=WPA2_PSK ：确认SSID与加密模式；
- [WiFi] wifi_connect(): connecting to SSID Mobile, bssid not set ：确认连接目标正确；
- [WiFi] sta_rx_data: data len=xx ：接收数据包，证明链路层正常；
- [IP] dhcp_start(): start ip address: 192.168.43.86 ：确认DHCP获取成功。

若日志中出现 wifi connect: No AP found ，说明扫描失败，需检查天线连接、信道设置或周围无可用AP。

5.2 连接失败的三级诊断法

当 WiFi.begin() 后长时间无法获取IP，按以下顺序排查：

第一级：物理层
- 使用手机WiFi分析仪APP，确认目标AP信号强度（> -65dBm为佳）；
- 检查ESP32开发板天线接口（IPEX或PCB天线）是否松动或短路；
- 测量WiFi模块供电电压（3.3V±0.3V），电压不稳会导致射频异常。

第二级：链路层
- 执行 esp_wifi_scan_start() ，打印扫描结果，确认能否发现目标AP；
- 若扫描不到，检查 wifi_config_t.ssid 是否包含不可见字符（如UTF-8 BOM）；
- 若扫描到但连接失败，用 esp_wifi_set_config() 中的 authmode 匹配AP的实际加密类型（WPA2 vs WPA3）。

第三级：网络层
- 连接成功后，用 ping 命令测试网关连通性（ ping 192.168.43.1 ）；
- 若能ping通网关但无法访问外网，检查 ip4_route_show() 输出，确认默认路由指向正确网关；
- 若 ping 不通网关，检查 esp_netif_get_ip_info() 返回的IP是否与网关在同一子网。

5.3 Web服务无法访问的精准定位

当AP模式下浏览器无法打开 192.168.4.1 ，按以下步骤定位：

1. 确认AP已启动 ：串口日志中应有 wifi ap start 字样，且 esp_wifi_get_mode() 返回 WIFI_MODE_AP ；
2. 确认DHCP服务运行 ：用另一台设备（手机）连接AP，查看是否获取到 192.168.4.x 网段IP；
3. 确认HTTP服务器启动 ：日志中应有 httpd_start(): server started on port 80 ；
4. 确认防火墙 ：Windows防火墙有时会拦截本地HTTP服务，临时关闭测试；
5. 确认浏览器缓存 ：强制刷新（Ctrl+F5）或使用隐身窗口，排除304 Not Modified缓存干扰。

曾遇到一个典型案例：AP模式下网页始终空白，日志显示HTTP服务已启动。最终发现是 httpd_resp_set_type() 中误设为 "text/plain" ，导致浏览器未按HTML解析，改为 "text/html" 后立即恢复正常。这提醒我们，HTTP头信息的细微错误，往往比网络连接问题更难察觉。

我在实际项目中踩过几次坑之后，养成了一个习惯：每次WiFi配置变更后，必用 tcpdump 抓包分析。例如，在电脑上执行 tcpdump -i wlan0 host 192.168.4.1 and port 80 ，可清晰看到ESP32是否收到了HTTP GET请求、是否返回了200 OK响应。这种底层视角，远比盯着串口日志有效。