html本身不负责传输，仅负责呈现；真正实现物联网控制需javascript调用网络api，后端再通过mqtt、coap等协议桥接设备。
HTML 本身没有“传输函数”——它不负责传输，只负责呈现；所谓“HTML传输”，实际是前端 JavaScript 调用网络 API，再由后端桥接到设备。选工具前必须先厘清这个责任边界，否则容易在前端堆砌无效代码。
为什么不能直接用 fetch() 或 XMLHttpRequest 控制物联网设备？
这两个是浏览器原生网络函数，能发 HTTP 请求，但物联网设备通常不直接暴露 HTTP 服务（尤其低功耗节点）。强行用 fetch() 直连设备 IP，大概率失败，原因包括：
- 设备没跑 Web 服务器（比如纯 LoRa/SX1278 节点只有串口或 SPI 接口）
- 设备处于深度睡眠，TCP 连接无法维持（
fetch()会超时或被拒绝） - HTTP 头部开销大（约 400+ 字节），对 BLE 广播或 Sub-1GHz 小包通信极不友好
真正该选的不是“HTML 函数”，而是后端协议适配层
低功耗设备的数据通路必须经过协议转换：前端发指令 → 后端接收 → 转成设备能响应的轻量协议 → 下发。关键选型点在后端侧，前端只需匹配其接口：
- 若设备接入 MQTT Broker（如 Mosquitto、EMQX），前端用
MQTT.js库 + WebSocket 连接，发送publish()到指定 topic（例如device/0x1234/control） - 若设备支持 CoAP（常见于 STM32L4 + u-blox SARA-R5 组合），后端需部署 CoAP 代理（如
node-coap），前端仍走fetch()，但目标是后端的 CoAP-to-HTTP 网关地址 - 若设备仅支持串口透传（如 SAMD21G + Ra-02 模块），前端必须通过 WebSocket 连后端串口服务（如
serialport+ws），不能绕过
前端 JS 工具链中唯一需要谨慎选的，是连接稳定性处理逻辑
低功耗设备响应慢、断连频繁，前端不能依赖默认 fetch 行为。必须封装重试、退避、离线缓存：
- 避免裸写
fetch("/api/light/on")，应封装为带指数退避的sendCommandWithRetry()函数 - 对 BLE 设备（如 Arduino Nano 33 BLE），优先用
Web Bluetooth API（需 HTTPS + 用户手势触发），而非 HTTP —— 它直接走 GAP/GATT，省去网络栈开销 - 状态同步不要轮询，改用后端推送：WebSocket 或 Server-Sent Events（SSE），减少空闲期心跳流量
最容易被忽略的是时间精度问题：前端用 Date.now() 计算上报间隔，但设备 RTC 可能漂移 ±20ppm；若你靠前端定时器唤醒休眠设备，半年后可能偏差数小时。真正可靠的唤醒必须由设备本地 RTC 或外部中断（如 LoRaWAN Class B beacon）驱动，前端只做指令下发和状态订阅。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
