嵌入式HTML解析的关键是资源可控与实时响应保障。应选用gumbo-parser，禁用JS/CSS支持，静态链接，预分配内存，避免动态分配与中断上下文调用，采用分阶段任务流和线性占位符替换，将HTML视为轻量参数协议而非渲染载体。
嵌入式设备上跑HTML解析，不是“能不能解析”，而是“解析完还能不能继续响应按键、上传传感器数据、维持WiFi连接”。内存紧、CPU弱、无虚拟内存、Flash写寿命有限——这些约束直接淘汰掉所有带Python运行时、DOM树全加载、自动GC的方案。
用 gumbo-parser 而不是 BeautifulSoup 或 html5-parser
gumbo-parser 是目前唯一被广泛验证能在裸机/RTOS/小资源Linux（如Buildroot + uClibc）上稳定工作的纯C HTML5解析器。它不依赖malloc以外的任何标准库功能，可静态链接，解析10KB HTML平均仅占12KB RAM（堆+栈），且全程无realloc调用——这对Flash寿命敏感的嵌入式场景至关重要。
- 编译时必须禁用
GUMBO_ENABLE_JS和GUMBO_ENABLE_CSS宏，它们会引入额外字符串处理逻辑和内存分配 - 不要用
gumbo_parse_with_options()传入自定义GumboOptions，除非你已确认max_errors设为0且allocator指向预分配的固定缓冲区 - 解析后立即调用
gumbo_destroy_output()，它的释放逻辑是线性的，不会触发递归栈溢出
避免在中断上下文或定时器回调里调用任何HTML解析函数
哪怕是最轻量的gumbo_parse()，内部也有状态机跳转和多次memcpy。在FreeRTOS中若从vTaskDelay()唤醒后立刻解析，可能因任务栈不足导致HardFault；在STM32 HAL中若在HAL_TIM_PeriodElapsedCallback()里调用，会显著拉长中断延迟，影响PWM或ADC采样精度。
- 把HTML接收、缓存、解析拆成三个独立任务：UART/HTTP接收 → ringbuffer暂存 → 低优先级空闲任务解析
- 解析前检查输入长度是否超过预设阈值（如
MAX_HTML_LEN = 4096），超长直接丢弃，防止OOM - 绝不使用
strstr()或strtok()在原始HTML字符串上做占位符替换——它们不可重入，且会修改原缓冲区，破坏后续解析
模板替换必须用预编译占位符 + 线性扫描
像Refresh_Html()这类函数，核心不是“解析HTML”，而是“安全替换”。它不构造DOM，不校验标签闭合，只做一次从左到右的strstr()扫描+memcpy()拼接，全程无动态分配，执行时间可预测（O(n+m)），适合放在主循环中每秒调用。
立即学习“前端免费学习笔记（深入）”；
- 占位符必须有统一前缀（如
"__A_"）和后缀（如"__"），禁止使用"{{var}}"这类需多层状态判断的语法 -
Parameter数组必须静态定义在RAM中（而非malloc），且para字段指向ROM字符串（节省RAM），value字段指向可变缓冲区（如char temp_str[16]） - 替换失败时返回
0而非报错，上层逻辑应直接发默认页面，而不是尝试重试——嵌入式没有“重试预算”
真正难的不是选哪个库，而是承认：在RAM ≤ 512KB、主频 ≤ 200MHz的设备上，HTML不该用来渲染复杂界面，而该作为参数交换的文本协议。解析函数只是管道工，不是建筑师。
