企业官网建设流程全解析

1. 为什么一个 .wasm 文件，还不能算真正的 ESP32 应用？

你手头刚编译出一个.wasm文件，双击打开能跑 demo，控制台输出“Hello from WebAssembly”，心里一热：成了！ESP32 上跑 WASM？这不就是边缘智能的终极形态吗？别急——我去年在做工业网关固件升级时，也卡在这个认知盲区里整整三周。当时把 Rust 编译的hello.wasm丢进 WAMR 运行时，串口打印出结果，兴奋地发了朋友圈，结果被一位做了十年嵌入式的老同事一句点醒：“你跑的是 wasm，但你没跑通 ESP32。”

这句话背后藏着五个硬性门槛：硬件抽象层缺失、实时性不可控、外设驱动不可达、内存模型不兼容、启动链路未打通。不是技术不行，而是“能运行”和“是应用”之间，隔着一整套嵌入式系统工程的骨架。WASM 在浏览器里是沙盒里的玩具，在 ESP32 上它得变成车间里的扳手——得能拧螺丝、测电压、扛中断、扛掉电。而目前绝大多数.wasm文件，连车间大门都没推开。

这不是对 WASM 的否定，恰恰相反，正因为它潜力太大，才更需要看清现状。你看到的热搜词里，“go 集成 wasm 虚拟机”“esp32 终端”“arduino esp32 网络服务”，全指向同一个趋势：开发者想用高级语言快速构建 ESP32 业务逻辑，绕过 C/C++ 的内存管理地狱。但现实是，.wasm文件本身只是字节码容器，它不带 GPIO 初始化代码，不包含 WiFi 连接状态机，不声明 ADC 采样精度，也不处理看门狗喂狗时机。它像一张乐谱，而 ESP32 是一架没调音、没装弦、甚至没组装好的钢琴。

真正能称为“ESP32 应用”的，必须满足三个刚性条件：可独立烧录、可响应硬件事件、可长期稳定运行超 72 小时。目前单靠.wasm文件，一条都不满足。它必须被嵌入到一个具备完整启动流程、外设抽象、资源调度能力的宿主固件中，才能获得“应用”身份。后面我会拆解这五个门槛怎么破——不是讲理论，而是告诉你我在 ESP32-S3 上实测过的 WAMR + ESP-IDF 混合架构里，每个模块怎么焊、怎么配、哪根线不能接反、哪个宏定义漏了会导致看门狗狂跳。

2. 核心障碍深度拆解：五个“不能算”的硬性原因

2.1 硬件抽象层（HAL）完全缺失：WASM 不认识 GPIO，就像人没见过插座

WASM 规范从设计之初就刻意剥离硬件访问能力。它的系统调用（syscalls）只定义了args_get、environ_get、clock_time_get这类通用接口，没有gpio_write、i2c_transfer、adc_read这类嵌入式刚需指令。这意味着，哪怕你用 Zig 写了一段完美控制 LED 闪烁的逻辑，编译成.wasm后，它根本不知道 ESP32 的 GPIO0 接在哪块寄存器上，更不知道如何置位/清零。

我做过对比实验：用 ESP-IDF 的gpio_set_level(GPIO_NUM_0, 1)控制 LED，底层实际执行的是对GPIO_OUT_REG寄存器第 0 位写1；而 WASM 运行时（如 WAMR）若要暴露该能力，必须在宿主固件中手动注册一个 host function，例如：

// 宿主固件中注册 GPIO 控制函数 static void wasm_gpio_set_level(void *env, int32_t pin, int32_t level) { gpio_set_level((gpio_num_t)pin, level); } // 然后在 WAMR 初始化时绑定： wasm_runtime_register_host_function(module, "env", "gpio_set_level", wasm_gpio_set_level);

这个过程不是自动的，而是逐个外设、逐个功能手工桥接。目前开源项目中，WAMR 官方示例只实现了基础文件 I/O 和简单数学运算，ESP32 特有的 WiFi、BLE、USB、PSRAM、LCD、SDIO 等 17 类外设，95% 无现成 host function 支持。你每要用一个外设，就得自己写 C 绑定、做参数校验、处理错误返回——这已经不是“写业务逻辑”，而是重写 HAL 层。

提示：有人尝试用 Emscripten 的-s EXPORTED_FUNCTIONS导出函数，但这在嵌入式环境失效。Emscripten 生成的 WASM 依赖浏览器 DOM API，而 ESP32 没有 DOM。强行移植会触发__syscall未实现错误，且无法链接libc中的_exit等基础符号。

2.2 实时性与中断响应失控：WASM 线程模型与 ESP32 FreeRTOS 天然冲突

ESP32 的灵魂是 FreeRTOS 实时操作系统，它通过优先级抢占式调度保证关键任务（如电机 PID 控制、CAN 报文收发）在微秒级响应中断。而 WASM 的线程模型基于 Web Workers，本质是协作式多任务：一个 WASM 模块执行时，除非主动 yield，否则不会让出 CPU。这在浏览器里没问题，但在 ESP32 上会直接导致看门狗复位。

我实测过：一段纯计算的 WASM 循环（如 100 万次浮点累加），在 ESP32-S2 上运行超过 800ms 就触发Task watchdog got triggered。因为 FreeRTOS 的 idle task 无法抢占 WASM 执行线程，导致看门狗计数器超时。解决方案不是“优化 WASM 代码”，而是重构执行模型：

• 方案 A（推荐）：将 WASM 模块作为 FreeRTOS task 运行，但必须在循环中插入vTaskDelay(1)或taskYIELD()，强制让出时间片；
• 方案 B：使用 WAMR 的wasm_runtime_call_wasm_aot异步调用机制，配合 event loop 轮询，但需自行管理上下文切换开销；
• 方案 C（高风险）：关闭看门狗或延长 timeout，但工业场景绝对禁止——曾有客户因关闭看门狗导致设备在电磁干扰下锁死，现场断电重启。

更深层问题是中断处理。ESP32 的 GPIO 中断、UART RX FIFO 满中断、WiFi 连接事件，全部由 FreeRTOS 的 ISR（中断服务程序）捕获并投递到对应 task。WASM 模块无法注册 ISR，也无法接收消息队列（QueueHandle_t）。你必须在宿主 C 代码中监听这些事件，再通过wasm_runtime_invoke_native主动调用 WASM 函数传参——这引入了至少 200μs 的延迟，对 10kHz 以上的 PWM 控制已不可接受。

2.3 内存模型不兼容：WASM 的线性内存 vs ESP32 的分段物理内存

WASM 定义了一个统一的 32 位线性内存空间（Linear Memory），所有数据读写都通过i32.load/i32.store指令操作偏移地址。而 ESP32 的物理内存是严格分段的：

问题在于：WASM 编译器（如 wasm32-unknown-elf）生成的二进制，假设内存是平坦连续的。当它尝试分配 1MB 线性内存时，ESP32 的 DRAM 根本不够——S3 最大 DRAM 仅 512KB，且需分给 FreeRTOS heap、TCP/IP stack、WAMR runtime 自身。我遇到的真实案例：一个 Rust WASM 模块声明memory (export "memory") 1 1（初始 1 页=64KB，最大 1 页），烧录后立即wasm_runtime_instantiate失败，日志显示allocate linear memory failed: out of memory。

解决路径只有两条：

• 静态裁剪：用wabt工具反编译 WASM，删除未使用的导出函数，用wasm-strip移除 debug section，将模块体积压到 128KB 以内；
• 动态映射：修改 WAMR 源码，在wasm_runtime_module_malloc中重定向内存分配至 PSRAM，但需处理 cache 一致性（ESP32 的 PSRAM 无硬件 cache，需手动cache_writeback_all）。

注意：ESP32-C3 的内存布局更复杂，其 400KB SRAM 分为 D/IRAM 两块，WASM 运行时必须显式指定WASM_RUNTIME_MODE_INTERP（解释模式）而非 AOT，否则 AOT 编译的 native code 无法在 IRAM 中执行。

2.4 启动链路断裂：WASM 不是固件，它无法替代 bootloader

一个真正的 ESP32 应用，必须通过esptool.py烧录为完整的固件镜像（firmware image），包含：

• bootloader（0x1000）：初始化 flash、设置 clock、跳转 app；
• partition table（0x8000）：定义 otadata、nvs、phy_init、factory 等分区；
• app binary（0x10000）：主程序入口，含.text、.data、.bss段；
• OTA data（0x9000）：支持空中升级的元数据。

而.wasm文件只是一个二进制 blob，没有 ELF 头，没有段信息，无法被 esptool 识别。你不能把它直接烧到0x10000地址——它没有入口函数（_start），没有重定位信息，更没有对rom中函数（如printf）的符号引用解析。

可行方案是将其作为资源文件嵌入 app binary：

1. 用xxd -i hello.wasm > wasm_data.h生成 C 数组；
2. 在 app 中wasm_runtime_load加载该数组；
3. 通过wasm_runtime_instantiate创建实例。

但这带来新问题：WASM 模块大小受 app binary 空间限制。ESP32 默认 factory 分区仅 1MB，扣除 bootloader（~16KB）、partition table（0x2000）、phy_init（0x1000），剩余约 900KB 给 app。若 WASM 模块超 500KB，就会挤压 FreeRTOS heap，导致xTaskCreate失败。

2.5 外设驱动栈未贯通：WASM 无法直接调用 IDF 的 driver API

ESP-IDF 的驱动架构是分层的：
Application Code → Driver API (e.g., i2c_master_init) → HAL (e.g., i2c_hal_cmd_begin) → Register Access

WASM 模块处于最顶层，但它无法调用i2c_master_init，因为该函数依赖 IDF 的esp_err_t类型、i2c_port_t枚举、i2c_config_t结构体——这些在 WASM 的 ABI 中不存在。你必须在宿主 C 代码中封装一层薄胶水（thin glue layer）：

// wasm_glue.c #include "driver/i2c.h" #include "wasm_export.h" // WASM 可调用的简化接口 int32_t wasm_i2c_write(uint8_t port, uint8_t addr, const uint8_t* data, uint32_t len) { i2c_cmd_handle_t cmd = i2c_cmd_link_create(); i2c_master_start(cmd); i2c_master_write_byte(cmd, (addr << 1) | WRITE_BIT, ACK_CHECK_EN); i2c_master_write(cmd, data, len, ACK_CHECK_EN); i2c_master_stop(cmd); esp_err_t ret = i2c_master_cmd_begin(port, cmd, 1000 / portTICK_PERIOD_MS); i2c_cmd_link_delete(cmd); return (ret == ESP_OK) ? 0 : -1; }

这个过程极其脆弱：

• 若data指针来自 WASM 线性内存，需用wasm_runtime_addr_to_native转换地址；
• 若len > 255，I2C FIFO 溢出，需分包处理；
• 若port为 1，但硬件只接了 I2C0，返回值无意义；
• 错误码ESP_ERR_INVALID_ARG在 WASM 中无法映射为有意义的字符串。

我统计过，为支持一个完整 I2C 设备（如 BME280 温湿度传感器），需封装至少 12 个 host function，覆盖初始化、读寄存器、写寄存器、批量读取、CRC 校验等，工作量相当于重写一遍驱动。

3. 实操路径：如何让 .wasm 真正成为 ESP32 应用的一部分

3.1 宿主固件架构选型：WAMR + ESP-IDF 是当前唯一生产级组合

市面上存在多个 WASM 运行时：WAMR（WebAssembly Micro Runtime）、Wasmer、WasmEdge、WASI-SDK。但在 ESP32 场景下，只有 WAMR 具备完整生产可用性，原因如下：

WAMR 被 Espressif 官方集成进 ESP-IDF v5.0+，路径为components/wamr。它提供两种模式：

• Interpreter Mode：内存占用小，启动快，适合资源受限设备（ESP32-D2WD）；
• AOT Mode：执行速度快 3–5 倍，但需预编译，且 AOT 文件需烧录到 flash 特定分区。

我推荐新手从 Interpreter Mode 开始，因为：

• 编译工具链简单：只需wamrc（WAMR AOT 编译器）非必需；
• 调试友好：WASM 源码行号可映射到日志；
• 内存可控：可通过wasm_runtime_set_max_thread_stack_size限制栈大小。

实操步骤：

1. 在 ESP-IDF Project 中启用 WAMR：

   # sdkconfig.defaults CONFIG_WAMR_BUILD_INTERP=y CONFIG_WAMR_BUILD_AOT=n CONFIG_WAMR_BUILD_LIBC_BUILTIN=y CONFIG_WAMR_BUILD_LIBC_WASI=n # 关闭 WASI，避免依赖 host filesystem

2. 添加 WAMR 组件依赖：

   # CMakeLists.txt idf_component_register(SRCS "main.c" "wasm_glue.c" INCLUDE_DIRS "." REQUIRES wamr)

3. 初始化 WAMR 运行时（必须在app_main()中，且早于任何 task 创建）：

   #include "wasm_export.h" #define DEFAULT_HEAP_SIZE (1024 * 1024) // 1MB heap for WASM static uint8_t wasm_heap[DEFAULT_HEAP_SIZE]; void app_main(void) { // 初始化 WAMR RuntimeInitArgs init_args = {0}; init_args.mem_alloc_type = Alloc_With_Allocator; init_args.mem_allocator = &mem_allocator; init_args.max_thread_stack_size = 8192; if (!wasm_runtime_full_init(&init_args)) { ESP_LOGE("WAMR", "Init failed"); return; } // 加载 WASM 模块 uint8_t *wasm_buf = NULL; uint32_t wasm_size = 0; read_wasm_from_flash(&wasm_buf, &wasm_size); // 自定义函数，从 partition 读取 wasm_module_t module = wasm_runtime_load(wasm_buf, wasm_size, error_buf, sizeof(error_buf)); if (!module) { ESP_LOGE("WAMR", "Load failed: %s", error_buf); return; } // 创建实例 wasm_module_inst_t inst = wasm_runtime_instantiate(module, DEFAULT_HEAP_SIZE, wasm_heap, error_buf, sizeof(error_buf)); if (!inst) { ESP_LOGE("WAMR", "Instantiate failed: %s", error_buf); return; } }

实操心得：wasm_runtime_instantiate的heap_size参数不是“最大可用内存”，而是“本次实例独占的 heap”。若设为 512KB，即使系统还有 1MB free heap，WASM 也无法申请更多。我建议初学者设为128 * 1024（128KB），后续根据wasm_runtime_get_exec_env_heap_used_size动态调整。

3.2 WASM 模块开发规范：Rust + wasm32-unknown-elf 工具链实战

选择 Rust 而非 C/C++ 编译 WASM，是因为 Rust 的所有权模型天然规避内存泄漏，且wasm-bindgen生态成熟。但必须使用wasm32-unknown-elf目标，而非wasm32-unknown-unknown（后者为浏览器专用）。

安装与配置：

# 安装 Rust target rustup target add wasm32-unknown-elf # 创建 lib crate（非 bin！因为 ESP32 不需要 _start） cargo new --lib my_wasm_app cd my_wasm_app # 修改 Cargo.toml [lib] crate-type = ["cdylib"] # 生成 .wasm，非 .so [dependencies] # 移除 std，使用 core + alloc #![no_std] #![no_main] #![no_core] [dependencies.core] version = "1.0" features = [] [dependencies.alloc] version = "1.0"

关键代码约束：

• 禁用 panic handler：ESP32 无std::panic，需自定义：

  #[panic_handler] fn panic(_info: &core::panic::PanicInfo) -> ! { loop {} // 或调用 abort() }

• 禁用浮点运算：ESP32-S2/S3 的 FPU 不兼容 WASM 的f32指令，开启-C target-feature=+soft-float：

  rustflags = [ "-C", "target-feature=+soft-float", "-C", "link-arg=--allow-multiple-definition" ]

• 导出函数必须为 extern "C"：

  #[no_mangle] pub extern "C" fn init_gpio(pin: u32) -> u32 { // 此处不能调用 GPIO API，只能返回状态码 // 实际 GPIO 操作由 host function 完成 0 }

编译命令：

cargo build --release --target wasm32-unknown-elf # 输出：target/wasm32-unknown-elf/release/my_wasm_app.wasm

体积优化技巧：

• 使用wasm-strip移除 debug 符号；
• 使用wasm-opt进行 DCE（Dead Code Elimination）：

  wasm-opt -Oz --strip-debug --strip-producers my_wasm_app.wasm -o optimized.wasm

• 检查体积：wc -c optimized.wasm，目标 ≤ 128KB。

3.3 外设桥接实操：以 WiFi 连接为例的完整 host function 实现

以最常见的 WiFi 连接需求为例，展示如何将 ESP-IDF 的esp_wifi_connect()封装为 WASM 可调用函数。

Step 1：定义 WASM 可调用接口

// wasm_wifi.c #include "esp_wifi.h" #include "wasm_export.h" // 存储 WiFi 配置（WASM 传入的字符串需拷贝） static char ssid[33] = {0}; static char password[65] = {0}; // WASM 调用：设置 SSID 和密码 int32_t wasm_wifi_config(const char* ssid_ptr, const char* pwd_ptr) { // 从 WASM 线性内存拷贝字符串 uint32_t ssid_len = strlen(ssid_ptr); uint32_t pwd_len = strlen(pwd_ptr); if (ssid_len >= 32 || pwd_len >= 64) return -1; memcpy(ssid, ssid_ptr, ssid_len); memcpy(password, pwd_ptr, pwd_len); ssid[ssid_len] = '\0'; password[pwd_len] = '\0'; return 0; } // WASM 调用：连接 WiFi int32_t wasm_wifi_connect() { wifi_config_t wifi_config = {0}; strcpy((char*)wifi_config.sta.ssid, ssid); strcpy((char*)wifi_config.sta.password, password); esp_wifi_set_mode(WIFI_MODE_STA); esp_wifi_set_config(WIFI_IF_STA, &wifi_config); esp_wifi_start(); // 同步等待连接（实际项目应改为异步事件回调） int retry = 0; while (retry++ < 20) { wifi_ap_record_t ap_info; if (esp_wifi_sta_get_ap_info(&ap_info) == ESP_OK) { return 0; // 成功 } vTaskDelay(500 / portTICK_PERIOD_MS); } return -1; // 超时 }

Step 2：注册 host function 到 WAMR

// 在 app_main() 中注册 static NativeSymbol native_symbols[] = { { "wifi_config", wasm_wifi_config, "(ii)i", NULL }, { "wifi_connect", wasm_wifi_connect, "()i", NULL }, }; wasm_runtime_register_natives("env", native_symbols, sizeof(native_symbols) / sizeof(NativeSymbol));

Step 3：Rust WASM 中调用

extern "C" { fn wifi_config(ssid_ptr: *const u8, pwd_ptr: *const u8) -> u32; fn wifi_connect() -> u32; } #[no_mangle] pub extern "C" fn connect_to_wifi(ssid: *const u8, pwd: *const u8) -> u32 { let ret = unsafe { wifi_config(ssid, pwd) }; if ret != 0 { return ret; } unsafe { wifi_connect() } }

关键细节：

• *const u8是 WASM 线性内存中的指针，需确保字符串以\0结尾；
• wifi_connect()中的vTaskDelay必须存在，否则阻塞 FreeRTOS scheduler；
• 实际项目中，应改用esp_event_handler_t注册IP_EVENT_STA_GOT_IP事件，再通过wasm_runtime_invoke_native回调 WASM 函数，避免轮询。

3.4 烧录与调试：将 WASM 模块嵌入固件的三种方式

方式一：编译期嵌入（推荐新手）

将.wasm文件转为 C 数组，与固件一起编译：

xxd -i my_app.wasm > wasm_bin.h

生成的wasm_bin.h内容类似：

unsigned char my_app_wasm[] = { 0x00, 0x61, 0x73, 0x6d, 0x01, 0x00, 0x00, 0x00, ... }; unsigned int my_app_wasm_len = 12345;

在代码中直接使用my_app_wasm和my_app_wasm_len。

优点：简单可靠，无需额外分区；
缺点：修改 WASM 需重新编译整个固件。

方式二：Flash 分区存储（推荐量产）

创建独立的wasm分区（partitions.csv）：

# Name, Type, SubType, Offset, Size, Flags wasm, data, 0, 0x200000, 1M,

烧录时单独烧录：

esptool.py --chip esp32s3 write_flash 0x200000 my_app.wasm

代码中读取：

#include "nvs_flash.h" #include "esp_partition.h" void read_wasm_from_flash(uint8_t** buf, uint32_t* size) { const esp_partition_t* partition = esp_partition_find_first( ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_DATA_UNDEFINED, "wasm"); if (!partition) return; *buf = malloc(partition->size); esp_partition_read(partition, 0, *buf, partition->size); *size = partition->size; }

优点：WASM 可 OTA 升级，固件与逻辑分离；
缺点：需管理分区大小，读取耗时（SPI flash ~80MB/s，128KB 需 1.6ms）。

方式三：SD 卡加载（适合开发调试）

使用 SDMMC 驱动挂载 SD 卡，从 FAT32 文件系统读取.wasm：

#include "sdmmc_cmd.h" // 初始化 SD 卡... FIL fil; f_open(&fatfs, &fil, "/app.wasm", FA_READ); f_read(&fil, wasm_buf, wasm_size, &br); f_close(&fil);

优点：热替换 WASM，无需烧录；
缺点：SD 卡可靠性低，工业环境禁用；增加 BOM 成本。

调试技巧：WAMR 提供wasm_runtime_set_exception_callback，可捕获 WASM trap：

void on_wasm_exception(const char* exception) { ESP_LOGE("WASM", "Exception: %s", exception); // 此处可触发看门狗复位或发送 OTA 错误日志 } wasm_runtime_set_exception_callback(on_wasm_exception);

4. 常见问题与避坑指南：踩过的坑比代码还多

4.1 问题速查表：高频故障与根因分析

4.2 独家避坑经验：那些文档不会写的细节

坑一：WASM 字符串传递的编码陷阱
WASM 线性内存中字符串是 UTF-8 编码，但 ESP-IDF 的strcpy期望 ASCII。若 Rust 中写let ssid = "你好";，UTF-8 编码为0xe4 0xbd 0xa0 0xe5 0xa5 0xbd，传给strcpy会截断为""。解决方案：强制转 ASCII：

#[no_mangle] pub extern "C" fn set_ssid_ascii(ssid_ptr: *const u8) -> u32 { let cstr = unsafe { CStr::from_ptr(ssid_ptr) }; let bytes = cstr.to_bytes(); // 过滤非 ASCII 字符 let ascii: Vec<u8> = bytes.iter().filter(|&&b| b < 128).copied().collect(); // 拷贝到全局 buffer... }

坑二：FreeRTOS heap 与 WASM heap 的竞争
WAMR 的wasm_runtime_instantiate从 FreeRTOS heap 分配内存，而xTaskCreate也从同一 heap 分配。若 WASM heap 设为 256KB，系统只剩 256KB 给 tasks，xTaskCreate易失败。我的解法：

• 在sdkconfig中增大CONFIG_ESP_SYSTEM_MEM_ALLOC_MODE为CONTINUOUS；
• 使用heap_caps_malloc(256*1024, MALLOC_CAP_INTERNAL | MALLOC_CAP_8BIT)为 WASM 单独分配内存；
• 在wasm_runtime_instantiate中传入该内存地址。

坑三：PSRAM 映射的 cache 一致性
当 WASM 模块大于 DRAM 容量，必须映射到 PSRAM。但 ESP32 的 PSRAM 无硬件 cache，而 CPU 有 data cache。若 WASM 修改 PSRAM 数据，CPU cache 中副本未更新，导致读取脏数据。必须在每次 WASM 内存操作前后执行：

Cache_WriteBack_All(); // 清空 cache // WASM 执行 Cache_Invalidate_DCache(); // 使 cache 失效

坑四：OTA 升级时 WASM 模块的原子性
若 WASM 存储在 flash 分区，OTA 升级固件时，旧固件可能仍在运行 WASM，新固件启动后读取到半更新的 WASM 文件。解决方案：

• 使用双分区：wasm_a和wasm_b，OTA 时先写入备用分区，再更新nvs中的 active flag；
• 在app_main()中添加校验：crc32(wasm_bin) == stored_crc，失败则回退。

4.3 性能实测数据：不同场景下的真实开销

我在 ESP32-S3-DevKitC 上实测了关键操作耗时（单位：μs）：

结论：WASM 适合逻辑密集型、IO 稀疏型任务（如 JSON 解析、规则引擎、轻量 AI 推理），不适合IO 密集型、实时性要求高的任务（如 PWM 生成、CAN 总线收发）。一个典型应用架构是：C 代码处理外设驱动和实时控制，WASM 模块处理业务逻辑和协议解析。

5. 未来演进与务实建议：什么情况下值得投入

5.1 当前技术边界：哪些场景已可用，哪些仍需等待

已可落地的场景（2024 年实测）：

• 固件配置引擎：用 WASM 解析 YAML/JSON 配置，动态生成 MQTT topic、HTTP endpoint、报警阈值；
• 协议转换器