html解析树无法跨核并行构建，因tokenizer和tree construction阶段受w3c规范约束，必须严格遵循字符流顺序性与上下文依赖性，所有主流引擎均在主线程串行执行。
浏览器引擎**不能真正并行构建HTML解析树**——Tokenizer 和 Tree Construction 两个阶段必须串行执行，这是由 HTML 规范强制要求的字符流顺序性和上下文依赖性决定的，和 CPU 核心数、架构（x86/ARM）或是否启用实验标志都无关。
为什么“Parallel HTML parsing”不是真正的多核并行
Chrome 的 Parallel HTML parsing 实验标志（chrome://flags/#enable-parallel-html-parsing）常被误解为“让 DOM 树构建跑在多个线程上”。实际它只做一件事：把 HTML 词法分析（tokenization）中**部分无状态的预扫描任务**（比如快速跳过注释、识别标签起始位置）卸载到后台线程，而真正的 token 解析、状态栈维护、DOM 节点创建、嵌套校验等仍全部在主线程完成。
- 遇到
<script></script>或未闭合的<textarea></textarea>时，后台线程必须立即暂停并同步回主线程——因为后续字节含义完全依赖当前 parser 状态 - ARM 设备上实测开启模拟多线程 tokenize 后，
domContentLoaded反而延迟 120ms，主因是线程间同步开销压倒收益 -
document.write()、innerHTML = hugeString等操作在 ARMv8-A 上会触发更重的 TLB flush 或 L1d 缓存失效，进一步削弱并行尝试效果
真正可并行的 HTML 相关环节有哪些
浏览器把“能并行”的事全放在 HTML 解析的**外围**，而不是树构建本身：
-
资源发现与下载并行：解析器在 tokenization 阶段一旦扫到
<link rel="stylesheet">、<img src>、<script async></script>，就立刻发起网络请求，这些请求彼此独立，受限于同源并发连接数（HTTP/1.1 下通常 6~8 个）或 HTTP/2 多路复用能力 -
预加载扫描器线程化：启用
Preload scanner threading后，预加载扫描（preload scanner）运行在独立线程，负责提前提取<link rel="preload">、@import中的 URL，但它不参与 DOM 构建，只把发现的资源丢进网络队列 -
SSR/SSG 阶段并行渲染：服务端用 Node.js
Worker Threads并行调用ReactDOMServer.renderToString()渲染不同路由的 HTML 字符串，每个 Worker 拥有独立的 DOM 构建上下文，互不干扰
哪些操作会让并行优化彻底失效
即使你启用了所有 chrome://flags 并配好启动参数，以下行为仍会强制退回到单线程阻塞模式：
- 页面中存在同步
<script src></script>：解析器一遇到就暂停 tokenization，等待 JS 下载+执行完毕才继续，整个 HTML 流水线中断 - 使用
@import引入 CSS：主 CSS 文件必须完整下载并解析后，才能发现其中的@import规则，子请求只能串行发起 - 在
里写document.write()：直接中断 parser，清空已构建的 DOM，从头开始解析新内容 - 服务端返回的 HTML 未按 64 字节对齐（如 Nginx
gzip_buffers配置不当）：ARM 平台 memcpy 性能惩罚放大，tokenizer 内部指针偏移变慢，抵消所有后台线程收益
别纠结“让 HTML 解析树跨核并行”，那在规范层就是不可能任务。重点应放在：确保资源尽早被发现、用 async/defer 切断 JS 阻塞、服务端对齐内存边界、把耗时计算挪到 Web Worker —— 这些才是浏览器真正允许你并行的地方。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
