micro-moustache是适配低算力MCU的轻量HTML生成方案，仅支持{{key}}等三个Mustache原语，需手动管理内存、防缓冲区溢出与XSS，不自动转义且不处理HTTP头。
低算力 MCU（如 STM32G0、ESP32-S2、CH32V203）通常只有几十 KB RAM、几百 KB Flash，且无操作系统或仅运行 FreeRTOS，根本跑不动 Node.js、浏览器引擎或完整模板库。所谓“HTML 生成函数工具”，在这里不是指前端框架，而是指能在裸机或轻量 RTOS 上执行的、用于动态拼接 HTML 响应字符串的 C/C++ 微型模板能力——核心诉求是：零动态内存分配、可预测栈开销、不依赖标准库以外的组件。
micro-moustache 是目前最匹配的嵌入式 HTML 生成方案
它专为 Arduino/ESP32/STM32 等平台设计，只实现 {{key}}、{{#key}} 和 {{^key}} 三个 Mustache 原语，编译后 Flash 占用 moustache_variable_t[] 数组长度决定，无递归、无 malloc、无 JSON 解析器。其他所谓“精简版”如 tinytemplate 或 hand-rolled sprintf 拼接，要么隐含堆分配风险，要么不支持条件节，维护成本反而更高。
-
moustache_variable_t的key必须指向 Flash 字符串（如PSTR("temp")），否则strcmp_P()失效 -
value成员若用 ArduinoString，需确保不频繁构造销毁，否则堆碎片会随运行时间恶化 - 不要尝试在中断上下文中调用
moustache_render()—— 它内部有循环和字符串比较，可能超时
避免使用 snprintf + 手动拼接的常见陷阱
很多开发者第一反应是用 snprintf(buf, sizeof(buf), "<div>%d</div>", value)，看似简单，但实际在低算力 MCU 上极易出问题：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 多数 MCU 工具链（如 ARM GCC for Cortex-M0+）默认禁用浮点和长整型支持，
snprintf对%lld或%f会静默截断或崩溃 - 格式字符串本身占 Flash，多个页面 → 多个长字符串 → Flash 迅速吃紧
- 无条件逻辑（比如“温度 > 35℃ 显示红色”）必须硬编码 if 分支，HTML 结构分散，后期改样式=全文件重审
- 缓冲区溢出风险高：
sizeof(buf)写错一位，snprintf不会报错，但后续 memcpy 可能越界
STM32 平台启用 micro-moustache 的关键配置
在裸机或 CubeMX + HAL 项目中接入，重点不在“怎么装”，而在“怎么防崩”：
立即学习“前端免费学习笔记（深入）”；
- 把模板字符串全部放进
const char template_html[] __attribute__((section(".rodata")))段，确保不进 RAM - 声明变量表时，显式指定长度：
moustache_variable_t vars[4] = { ... };，禁止用sizeof(vars)/sizeof(vars[0])计数（编译器可能优化掉） - 调用前检查输入数据有效性：若
value来自 ADC 采样，需先限幅再转字符串，避免String(-9999999)生成过长文本撑爆输出缓冲区 - HTTP 响应头必须手动写，
moustache_render()只负责 body；别指望它自动加Content-Type: text/html
真正容易被忽略的点是：micro-moustache 不做任何 HTML 转义。如果你把用户输入的设备名称（如 "<script>alert(1)</script>"）直接塞进 value，就会产生 XSS。这不是 bug，是设计取舍——嵌入式 Web 页面本就不该接收不可信输入。若业务真需显示外部字符串，必须在填入 value 前手动替换 <、>、" 为对应实体，且这个替换函数不能用 strcat，得用预分配缓冲区的 while 循环实现。
