同步脚本在中让首屏白屏更久，因其将js执行提前至dom树几乎为空阶段，浏览器暂停html解析、阻塞dom构建与渲染；而defer脚本可保序且不卡首屏，template能绕过解析开销，嵌套超6层会显著放大主线程竞争延迟。
同步<script>在<head>里为什么让首屏白屏更久</script>
不是脚本本身“卡住”了页面，而是它把JS执行时机提前到了DOM树几乎为空的阶段。浏览器遇到没有async或defer的<script></script>，会立刻暂停HTML解析器，把主线程控制权交给JS引擎。此时哪怕里只写了<h1>Hello</h1>，它也进不了DOM树，更不会触发样式计算和绘制。
- 同步脚本在
：DOM树为空，JS执行完前页面完全空白 - 同步脚本在
前：DOM已基本就绪，但JS仍会阻塞paint任务，用户可能看到无样式的文字 -
defer脚本：下载不阻塞解析，执行推迟到DOM解析完毕、DOMContentLoaded前——这是结构层唯一能保序且不卡首屏的方案
嵌套超过6层的如何放大主线程竞争延迟浏览器主线程顺序处理DOM构建 → 样式计算 → 布局 → 绘制。每多一层嵌套，样式继承链就拉长一节，布局计算复杂度非线性上升。JS执行期间这些任务全被挂起；等JS结束，浏览器要一口气补完积压工作，用户感知就是“点了按钮，界面卡顿半秒才响应”。
- 6层以上嵌套（如
<div><section><div><div><div>）会让样式计算耗时翻倍，尤其含<code>*{}或inherit <table>布局比<code>flex多一次整行解析等待，JS执行完后的回流成本更高- Chrome DevTools → Elements → 右键节点 → “Show DOM properties” 查
node.depth，超6层就该重构
为什么能绕过HTML解析与JS执行的线程争抢
<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>会被忽略，事件监听必须手动绑定
DOCTYPE错误或标签未闭合怎样让CSS失效而不报错
HTML结构不合法，CSS就大概率失效或错位——不是浏览器“不支持”，而是它根本没按你设想的方式解析DOM。比如DOCTYPE缺失或写错，浏览器进入怪异模式（document.compatMode === "BackCompat"），此时flexbox、grid、@supports甚至calc(100vh - 60px)都可能被忽略或算成0。
- 必须放在第一行且仅此一行；大小写不敏感，但
小写是通用实践
-
<nav><table><tr><th>Home</th></tr></table></nav>这种错乱嵌套，浏览器会强行纠错：提前闭合<nav></nav>、丢弃孤立nav table tr th选择器匹配不到任何节点
<table>内只允许<code><thead>、<code><tbody>、<code><tfoot>、<code><tr>，不能直接放<code><th>
<li>用W3C Validator或VS Code插件“Auto Close Tag”实时拦截未闭合问题</li>
<p>结构松动比JS慢更难排查——浏览器不会报错，只会默默按自己的逻辑重建DOM树，而你的CSS选择器早已失去目标。</p>
</th>
浏览器主线程顺序处理DOM构建 → 样式计算 → 布局 → 绘制。每多一层嵌套，样式继承链就拉长一节，布局计算复杂度非线性上升。JS执行期间这些任务全被挂起；等JS结束，浏览器要一口气补完积压工作，用户感知就是“点了按钮，界面卡顿半秒才响应”。
- 6层以上嵌套（如
<div><section><div><div><div>）会让样式计算耗时翻倍，尤其含<code>*{}或inherit <table>布局比<code>flex多一次整行解析等待，JS执行完后的回流成本更高- Chrome DevTools → Elements → 右键节点 → “Show DOM properties” 查
node.depth，超6层就该重构 - 直接
innerHTML = htmlStr：每次都要重新解析、构建节点、触发重排预备，JS执行期间无法做这事 - 克隆
template.content：只做内存复制，不触发布局/样式计算，JS执行完立刻可插入 - 注意：
template.content是DocumentFragment，不能直接querySelector，得先挂载或用querySelectorAll遍历 - 模板里的
<script></script>和<style></style>会被忽略，事件监听必须手动绑定 - 必须放在第一行且仅此一行；大小写不敏感，但
小写是通用实践 -
<nav><table><tr><th>Home</th></tr></table></nav>这种错乱嵌套，浏览器会强行纠错：提前闭合<nav></nav>、丢弃孤立，结果是nav table tr th选择器匹配不到任何节点 <table>内只允许<code><thead>、<code><tbody>、<code><tfoot>、<code><tr>，不能直接放<code><th> <li>用W3C Validator或VS Code插件“Auto Close Tag”实时拦截未闭合问题</li> <p>结构松动比JS慢更难排查——浏览器不会报错，只会默默按自己的逻辑重建DOM树，而你的CSS选择器早已失去目标。</p> </th>
为什么能绕过HTML解析与JS执行的线程争抢
<template></template>的内容不参与HTML解析流程，也不触发JS执行、资源加载或样式计算。它只是内存中一个惰性的DocumentFragment。当你用document.importNode(template.content, true)克隆插入时，浏览器跳过了从字符串解析HTML的全部开销——这部分原本要跑在主线程上，和JS执行争时间片。
DOCTYPE错误或标签未闭合怎样让CSS失效而不报错
HTML结构不合法，CSS就大概率失效或错位——不是浏览器“不支持”，而是它根本没按你设想的方式解析DOM。比如DOCTYPE缺失或写错，浏览器进入怪异模式（document.compatMode === "BackCompat"），此时flexbox、grid、@supports甚至calc(100vh - 60px)都可能被忽略或算成0。
