html结构虽不能干预线程竞争，但能决定竞争触发时机、瓶颈暴露环节及关键内容优先渲染；script位置影响首屏性能本质是改变js执行与dom构建的相对时序。
HTML结构本身不能“干预”线程竞争——因为渲染线程和JS引擎线程的互斥是浏览器主线程的底层调度机制，不可绕过。但结构写法能决定**何时触发竞争、在哪一环暴露瓶颈、以及能否让关键内容先渲染出来**。
为什么 <script></script> 放在
不是脚本位置“导致”阻塞，而是它让 JS 执行时机提前到了 DOM 构建最开始阶段。浏览器一旦遇到同步 <script></script>（无 async 或 defer），就会暂停 HTML 解析器，把控制权交给 JS 引擎。此时哪怕 里只写了 <h1>Hello</h1>，它也进不了 DOM 树，更不会参与样式计算或绘制。
- 同步脚本在
：DOM 树几乎为空，JS 执行完前，页面完全空白 - 同步脚本在
底部：DOM 已基本构建完成，但 JS 执行仍会阻塞后续渲染任务（如 paint），用户可能看到文字但无样式或交互 -
defer脚本：下载不阻塞解析，执行被推迟到 DOM 解析完毕后、DOMContentLoaded前——这是结构层唯一能“保序且不卡首屏”的方案
<template></template> 不执行脚本，但能规避 JS 线程对 DOM 构建的干扰
<template></template> 的内容不参与 HTML 解析流程，也不触发 JS 执行、资源加载或样式计算。它只是内存中一个惰性的 DocumentFragment。当你用 document.importNode(template.content, true) 克隆插入时，浏览器跳过了从字符串解析 HTML 的全部开销——这部分原本要跑在主线程上，和 JS 执行争时间片。
- 直接
innerHTML = htmlStr：每次都要重新解析、构建节点、触发重排预备，JS 执行期间无法做这事 - 克隆
template.content：只做内存复制，不触发布局/样式计算，JS 执行完立刻可插入 - 注意：
template.content是DocumentFragment，不能直接querySelector，得先挂载或用querySelectorAll遍历 - 模板里
<script></script>和<style></style>会被忽略，事件监听必须手动绑定
嵌套过深的 <div> 会放大线程竞争的感知延迟
<p>浏览器主线程要顺序处理 DOM 构建 → 样式计算 → 布局 → 绘制。每多一层嵌套，样式继承链就拉长一节，布局计算复杂度非线性上升。当 JS 正在执行时，这些任务全被挂起；等 JS 完了，浏览器要一口气补完所有积压的样式和布局工作——用户感知就是“点了按钮，界面卡顿半秒才响应”。</p>
<ul><li>6 层以上嵌套（如 <code><div><section><article><div><div><div>）会让样式计算耗时翻倍，尤其含通配符选择器（<code>*{}）或 inherit
<table> 布局比 <code>flex 多一次整行解析等待，JS 执行完后回流成本更高
container-wrapper-inner），用语义标签（<main></main>、<nav></nav>）替代，能减少 DOM 节点数和继承路径node.depth，超 6 就该重构真正能动手改的，从来不是线程模型本身，而是结构如何把“可渲染内容”推到解析流程前端、把“可延迟逻辑”推到执行队列后端。最容易被忽略的是：一个没闭合的 <div> 会导致浏览器纠错重建 DOM 树，这过程全在主线程上跑，和 JS 执行抢同一块时间片——它不报错，但会让所有后续优化失效。</div>
