低内存安卓设备上HTML页面崩溃主因是WebView layout阶段内存溢出或主线程卡死；需将行内元素改用div+inline-block、分帧注入（requestIdleCallback）、限制首屏节点≤500并控制DOM深度≤6。
低内存安卓设备（如 2GB RAM 的 Android 12/13）上，HTML 页面崩溃通常不是 JS 报错，而是 WebView 在 layout 阶段内存溢出或主线程卡死——document.querySelectorAll('*').length 超过 2000 就该干预，首屏节点必须压到 ≤500。
为什么 display: inline 标签堆叠会直接导致白屏
每个 <span> 或 <a> 都参与文本流重排、换行计算和空白合并。低端设备上，几千个行内元素会让浏览器在 layout 阶段维护的布局上下文远超内存阈值，DOM 树遍历都可能失败。这不是样式问题，是渲染引擎底层资源耗尽。
- 别用
<span class="tag">xxx</span>渲染标签云、筛选项等列表型内容 - 统一改用
<div class="tag-inline">xxx</div>，并加 CSS：.tag-inline { display: inline-block; vertical-align: top; margin: 0; padding: 0; } - 必须设
vertical-align，否则混排图标或数字时基线错乱；禁用float、width，避免触发 BFC
批量注入 DOM 节点时怎么避免卡死
即使换成 <div>，一次性塞入 5000 个节点仍会让 WebView 在首次 render 时卡住。关键不在“要不要分片”，而在“谁来调度空闲时机”。
- 优先用
requestIdleCallback：它会在浏览器空闲帧执行，不抢占用户交互，实测 Android 8–13 下每帧处理 200–300 个节点最稳 - Android 7 及以下需 fallback 到
setTimeout(..., 16)（不能用 0），否则节流失效，容易堆积任务 - 示例逻辑中
container.append(chunk.map(...))必须传入 HTML 字符串数组，而非已创建的 Element 节点——后者会提前触发 layout 计算
DOM 深度 > 6 层时，getComputedStyle 为什么突然变慢
浏览器计算样式要递归回溯祖先链，每深一层，选择器匹配、继承属性传播、布局上下文创建开销都叠加。深度达 12 时，单次 getComputedStyle 在低端机上可能卡顿 80ms+。
立即学习“前端免费学习笔记（深入）”；
- 删掉无语义 wrapper：
<div><div><div><main>...</main></div></div></div>→ 直接用<main> - 用语义化标签替代 div 堆叠：
<section>、<article>、<nav>不增加 node.depth - CSS 选择器写成
.card .title，别用div div h2—— 后者强依赖结构深度，一改就崩
CI 中如何自动守住 DOM 节点数红线
靠人眼检查或手动跑 document.querySelectorAll('*').length 完全不可靠。必须把检测嵌入自动化流程，否则上线即破防。
- 在 Puppeteer / Playwright 测试脚本里加断言：
expect(await page.$eval('body', el => document.querySelectorAll('*').length)).toBeLessThan(2000) - 对首屏页面单独校验：
await page.$eval('main', el => document.querySelectorAll('*').length)，排除懒加载区域干扰 - 若 SSR 输出含大量 wrapper（如 CMS 自动注入的
<div class="container"><div class="row">），优先用 CSSgap替代，或服务端模板层过滤空容器
真正危险的从来不是节点总数，而是那些藏在 node.depth > 6 结构里的隐式开销——它们不会报错，但会让 offsetTop、getBoundingClientRect 等调用变成卡顿源头，且难以定位。
