因为嵌入式WebKit/Blink内核默认禁用document.write的同步阻塞逻辑，DOM关闭后调用会丢弃内容或触发内核abort，属资源受限设备的主动防御策略；替代方案应优先用innerHTML写入容器节点，动态脚本改用createElement异步加载。
为什么 document.write 在嵌入式终端上会卡死或白屏
因为多数嵌入式 WebKit/Blink 内核（如 QtWebEngine 5.12、MiniBrowser for ARM）默认禁用或阉割了 document.write 的同步阻塞逻辑，尤其在 DOM 已关闭（document.readyState === 'complete'）后调用，会直接丢弃内容或触发内核级 abort。这不是 bug，而是资源受限设备的主动防御策略。
- 实测发现：在 256MB RAM + 单核 Cortex-A7 设备上，连续 3 次
document.write('<div>test</div>')就可能使渲染线程 hang 超过 800ms - 替代方案必须绕过 DOM 构建阶段——优先用
innerHTML直接写入document.body或已存在的容器节点 - 若必须动态注入脚本，改用
document.createElement('script')+element.src异步加载，严禁拼接字符串后appendChild执行内联代码
如何用 DOMParser 安全解析精简 HTML 片段
DOMParser 比正则/字符串替换更可靠，且在大多数嵌入式浏览器中保留完整支持（Chrome for ARM、WebKitGTK 2.34+）。但它对非法标签极其敏感——比如缺少闭合的 <img> 或自闭合的 <br/> 在旧内核里会抛 SyntaxError 而非静默修复。
- 务必先 normalize：用
str.replace(/<\/?([a-z][^>]*)\/?>/gi, (m, t) => m.toLowerCase())统一标签大小写 - 强制补全常见单标签：
str.replace(/<(img|br|hr|input|meta|link)[^>]*>/gi, '<$1>') - 解析后只取
doc.body?.childNodes，忽略head和文档类型节点，避免触发样式重计算 - 性能提示：一次解析不超过 4KB 字符串，否则在 300MHz CPU 上耗时可能突破 120ms
内联 CSS 与 style 属性的取舍边界在哪里
嵌入式终端的 CSS 引擎（尤其是 WebKit 的旧版 StyleResolver）对 class 选择器链长度极度敏感。当 .container .item .label span 超过 4 级，匹配耗时会指数增长；但纯 style 属性无此问题，且跳过选择器解析阶段。
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
- 适用
style属性：静态文本、图标、固定尺寸控件（如<button style="width:80px;height:32px;background:#007acc">） - 保留 class 的场景：需响应式缩放的容器、复用率 > 3 次的组件、含伪类（
:hover）的交互元素——此时必须把 class 定义压缩进<style>标签并放在<head>顶部 - 禁用项：
@import、CSS 变量（--color）、calc() 表达式——它们在libwebview中常被忽略或解析失败
真实环境下的首屏时间压测关键点
不要信 window.performance.timing.domContentLoadedEventEnd ——嵌入式内核常不实现 Performance API，或返回 0。真指标只能靠外置信号：GPIO 电平翻转 + 串口日志打点，或用 requestIdleCallback 回调内执行 console.timeEnd('render') 并输出到 localStorage。
立即学习“前端免费学习笔记（深入）”；
- 测试前必须关闭调试器：Chrome DevTools 远程调试会额外占用 15–20MB 内存，导致 GC 频繁，首屏延迟虚高 300ms+
- 对比基准要锁定：同一固件版本、同一屏幕分辨率（如 800×480）、禁用硬件加速（
--disable-gpu参数），否则 GPU 启用状态不同会导致帧率波动达 2x - 最容易被忽略的是字体加载：系统未预装的
font-family会触发网络回退或空白等待，默认超时长达 3s。解决方案是用@font-face声明 base64 编码的 WOFF2 字体，并设置font-display: swap
