边缘网关需流式注入HTML结构以嵌入实时设备数据，避免回源渲染；应使用Swoole+html5lib流式解析，在语义化script标签中注入转义JSON，并按设备型号映射Modbus寄存器，分层协作CDN与网关注入且缓存键须含设备上下文。
边缘网关为何要处理 HTML 文档结构注入
因为 HTML 不是静态资源，而是需要按设备能力、网络状态、用户角色动态生成的交互载体。在 openclaw-gateway 或工业边缘网关中，直接透传原始 HTML 会丢失本地上下文——比如温湿度传感器当前值、PLC 设备告警状态、Wi-Fi 信号强度，这些数据本就在边缘侧实时存在，却硬要回源到中心服务渲染再下发，既增加延迟又浪费带宽。
真正合理的做法，是让网关在转发 HTML 前做一次轻量级结构注入：把 data-* 属性、script 片段或内联 JSON 插入 DOM 树，而不是替换成完整页面。这要求网关具备 HTML 解析与重写能力，但又不能像浏览器那样全量解析——必须低开销、流式处理、可中断。
用 Swoole + html5lib 实现流式 HTML 注入（PHP 边缘场景）
PHP 在边缘节点跑 Swoole Server 时，常见错误是用 file_get_contents() 读取整个 HTML 文件再 str_replace()，这会导致内存暴涨、阻塞协程、无法处理超大模板。正确路径是流式解析 + 按需注入：
- 用
html5lib的Html5Parser配合TreeWalker，监听startTag和endTag事件，只对body或指定id="device-data"的节点做操作 - 注入点优先选
<script type="application/json" id="edge-context">这类语义化容器，避免污染业务逻辑脚本 - 注入内容必须 JSON 序列化且
htmlspecialchars()转义，防止 XSS；不要直接拼接innerHTML - 示例片段：
echo json_encode(['temp' => $sensor->read(), 'ts' => time()]);写入上述script标签体，前端用JSON.parse(document.getElementById('edge-context').textContent)读取
Modbus 设备页的 HTML 动态分发陷阱
工业现场常把 HMI 页面打包成静态 HTML 放在网关上，但不同型号 PLC 的寄存器地址映射不同。若用统一 HTML，靠 JS 在前端查 Modbus 表再渲染，就违背了边缘实时性原则——JS 请求串行、无缓存、易超时。
立即学习“前端免费学习笔记（深入）”；
更稳妥的做法是网关层完成协议适配与结构绑定：
- 配置文件里定义
modbus_map.json：每个设备型号对应一组register_address → field_name映射 - 网关收到请求时，先查设备类型，再用
DOMDocument::getElementById()定位占位符（如data-register="40001"），替换其textContent - 禁止在 HTML 中写死
http://gateway-ip/api/modbus?addr=40001这类 AJAX 地址——边缘网关应屏蔽后端细节，所有数据已预加载 - 注意
Content-Length头必须重算，Swoole 的response->end()不自动更新，否则浏览器卡在 loading
CDN 边缘节点与自建网关的 HTML 分发分工
别把所有 HTML 注入逻辑堆在物理网关上。CDN 边缘（如 Cloudflare Workers、阿里云 EdgeRoutine）适合做通用层注入：用户身份、地域标签、A/B 测试开关；而 openclaw-gateway 这类设备侧网关，专注设备上下文注入：传感器值、本地规则触发状态、固件版本。
两者通过 HTTP Header 协作，例如：
- CDN 注入后加
X-Edge-Injected: cdn - 网关检测到该 Header 存在，跳过重复注入，只追加
X-Device-Context: ok - 若网关发现
X-Edge-Injected缺失，说明请求绕过了 CDN，此时才执行全量注入逻辑
这种分层注入容易被忽略的是缓存键设计——必须把注入字段（如设备 ID、固件版本）纳入 Cache-Key，否则不同设备拿到同一份 HTML 就会错乱。
