超长单行html不会直接触发tokenizer缓冲区溢出，但会加剧token缓存扩容、嵌套栈溢出及旧版webview单token长度限制等风险。
超长单行HTML会触发Tokenizer缓冲区溢出吗
浏览器 HTML 解析器（如 Blink 的 HTMLTokenizer）本身不以“行”为单位切分输入，而是按字节流逐字符推进。所谓“超长单行”，本质是连续无换行符的巨量字符（比如 200KB 的 <div><p>...</p></div> 串成一行）。这种结构不会直接导致缓冲区溢出，但会显著放大三个底层压力点：
-
HTMLTokenizer在构建 token 时需临时缓存未闭合标签名、属性名、属性值等内容，单行中嵌套过深或属性值过长（如未截断的 base64 字符串）会让 token 缓冲区反复扩容 - Tree Construction 阶段需维持未闭合元素栈（open elements stack），单行中若含 500+ 层嵌套
<div>，栈深度可能逼近 V8 的调用栈限制，引发 <code>RangeError: Maximum call stack size exceeded - 某些旧版 WebView（如 Android 4.4 System WebView）对单 token 长度有隐式限制（约 64KB），超过后可能静默截断或解析中断
- 浏览器在遇到超长 token 时，会尝试回溯查找最近的合理断点；换行符是天然的语义边界，删除后回溯成本陡增，尤其在含大量内联 JSON 或
<script type="application/json"></script>的页面中 - 若原始 HTML 含
<pre class="brush:php;toolbar:false;"></pre>或<textarea></textarea>，而你又手动启用了removeRedundantAttributes，可能误删<pre class="brush:php;toolbar:false;" wrap="off"></pre>中的wrap属性，改变其渲染行为 - 更隐蔽的是：某些服务端模板引擎（如 EJS、Handlebars）在生成单行 HTML 时，会把条件逻辑（如
）也压进同一行，导致 JS 引擎在解析内联脚本时无法准确定位错误位置 -
innerHTML = hugeString会一次性触发完整解析 + 节点创建 + 样式计算 + 布局，Chrome 下超过 5MB 就极易触发主线程长时间占用 - 即使字符串只有 1MB，若含 5 万个
<div class="item"> 且每个都带内联 style，样式计算耗时会指数级上升 <li>正确做法是先用 <code>DOMParser解析成文档对象，再按节点数切片（建议每批 200–300 个节点），用DocumentFragment中转，并配合requestIdleCallback让出主线程 -
<script>for(let i=0;i<1e6;i++){/<em> 无换行的长循环 /}</script>会直接阻塞解析，且无法被defer或async缓解 -
<style>.a{color:red}.b{font-size:12px}...（连续 10 万字）</style>会导致 CSSOM 构建延迟，进而阻塞渲染 - 如果内联
<script></script>中包含document.write()，哪怕只写一次，也会清空当前文档流并重置整个解析器，本地file://环境下尤为敏感
为什么压缩工具把所有换行删掉反而更危险
html-minifier-terser 默认启用 collapseWhitespace: true，它会把所有空白（包括换行）替换成单空格——这看似“压缩”，实则抹去了天然的解析节奏锚点。问题在于：
实际卡顿往往不是解析慢，而是 DOM 构建阻塞
你看到“页面白屏 3 秒”，大概率不是 HTMLTokenizer 卡住，而是后续 DOM 构建阶段同步阻塞主线程：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
真正该警惕的“单行陷阱”是 script 和 style 内联内容
比起 HTML 标签本身，更危险的是单行内联脚本和样式：
单行 HTML 本身不致命，但它是资源失控、模板滥用、构建配置错误的集中暴露面——别盯着“行数”，去查 transfer size、DOM node count 和 main thread blocking time。
