html结构错误会直接卡住渲染线程，因非法嵌套触发浏览器容错修复，重建dom片段并反复重排重绘；ssr hydration时dom不一致还会导致react/vue丢弃子树重挂载。
为什么HTML结构错误会直接卡住渲染线程
浏览器解析HTML时，一旦遇到非法嵌套（比如 <p></p>
<div></div>
<p></p>、把 <div> 提到外面、补空标签。这个过程不是“悄悄修好”，而是重建DOM片段，触发多次重排（Layout）和重绘（Paint），尤其在大量卡片或列表中反复出现时，主线程会被持续抢占。<p>更隐蔽的是服务端渲染（SSR）场景：服务端输出的结构合法，但客户端 hydration 时因结构被浏览器修正，导致 DOM 树不一致，React/Vue 被迫丢弃整个子树重新挂载——这不是 JS 执行慢，是 HTML 本身让渲染线程反复回退重来。</p>
<ul><li>
<code><p></p> 内不能放 <div>、<code><section></section>、<ul></ul> 等块级容器<ul></ul> / <ol></ol> 的直接子元素只能是 <li>，放 <div class="item"> 会导致列表语义丢失、样式失效、屏幕阅读器跳过<li><code><table> 必须显式包含 <code><tbody>，否则浏览器自动补的 <code><tbody> 位置不可控，CSS 选择器（如 <code>tbody tr:nth-child(odd)）可能匹配失败动态生成卡片时事件监听器绑定失效的根源
常见写法是给每个按钮加相同 id（如 id="incrementBtn"），再用 document.getElementById('incrementBtn') 绑定事件——结果永远只生效第一个。这不是 JS 事件机制问题，是 HTML 规范明确要求 id 值全局唯一，浏览器只返回第一个匹配节点。
真正可行的路径只有两条：用类名 + 事件委托，或用数据属性区分实例。后者更可控，尤其在 SSR + hydration 场景下不会因 DOM 顺序微调而失配。
- 避免
id重复：改用class="btn-increment"或data-action="increment" - 绑定事件必须走委托：在父容器（如
class="container"）上监听click，再用e.target.matches('[data-action="increment"]')判断来源 - 若需传参（如商品 ID），不要靠闭包捕获循环变量，改用
e.target.dataset.productId取值
script 加载时机错位引发的 DOM 访问失败
document.getElementById 返回 null 的根本原因，90% 是脚本执行时 DOM 还没就绪——不是代码写错了，是执行时机踩进了浏览器解析流水线的“空窗期”。 里同步加载的脚本，在 开始解析前就执行了；而放在 前的脚本，虽能保证 DOM 就绪，却无法利用 async 或 defer 的并行加载优势。
- 首选方案：给
<script></script>加defer属性，它会等 HTML 解析完成再执行，且保持顺序，适合操作 DOM 的逻辑 - 次选方案：监听
DOMContentLoaded，但注意别和load混用——load等所有资源（图片、CSS）都加载完才触发，延迟远高于必要 - 绝对避免：在
中直接调用getElementById，除非你确定目标元素是内的 meta 或 link
HTML语义缺失如何拖慢渲染与可访问性链路
用 <div class="button"> 替代 <code><button></button>，表面功能正常，实则切断了三条关键链路：浏览器原生聚焦/键盘交互支持、屏幕阅读器语义播报、以及 CSS 的 :focus-visible 和 :disabled 自动状态管理。这些缺失不会报错，但会让渲染线程多做一堆无障碍适配工作，且 JS 不得不手动模拟 focus、keydown、aria-* 等行为，增加执行负担。
- 表单控件必须用原生标签：
<input type="radio">配<label for="id"></label>，而非div+ click 事件 - 导航区块用
<nav></nav>，主内容区用<main></main>，不仅利于 SEO，也减少浏览器为推断语义做的额外计算 - 避免
role模拟原生语义（如role="button"），除非你完整实现了键盘操作、焦点管理、状态同步
实际项目里最常被忽略的，是 HTML 结构合法性对渲染线程的隐性消耗——它不抛错、不报警，只默默拉长 TTFB 后的 Layout 时间，尤其在低端设备或复杂 SSR 页面中，这种“静默卡顿”比 JS 执行慢更难定位。
