hidden 属性由 HTML 解析器在解析阶段识别并标记元素为逻辑不可见，跳过布局、绘制与合成，且强制覆盖 CSS display 声明；它同步移除元素于可访问性树和表单序列化，但受更强 CSS 规则压制。
hidden 属性在渲染引擎中如何被识别
浏览器渲染引擎（如 Blink、Gecko、WebKit）在 HTML 解析阶段就识别 hidden 属性的存在，不解析其值——只要 token 中包含该属性名，就标记该元素为“逻辑不可见”。它不是 CSS 解析器的工作，而是 HTML 解析器与 DOM 构建阶段协同完成的语义标记。
这个过程发生在样式计算（style computation）之前：元素已插入 DOM 树，但渲染引擎会跳过它的布局（layout）、绘制（paint）和合成（composite）流程。你调用 el.getBoundingClientRect() 会立刻返回全零对象，el.offsetHeight 为 0，且该元素子树不会出现在渲染树（render tree）中。
为什么 display: none 不等于 hidden 的行为
display: none 是 CSS 层面的呈现控制，依赖样式计算结果；而 hidden 是 HTML 层面的语义声明，强制覆盖样式层默认行为。即使你写了 div { display: block !important; }，只要元素有 hidden 属性，现代浏览器仍会应用 display: none（这是 HTML5 规范强制要求）。
- 例外情况仅出现在显式 CSS 覆盖：
[hidden] { display: block !important; }—— 这属于反模式，破坏语义意图 -
display: none可被媒体查询、CSS-in-JS 动态注入等覆盖；hidden不受这些影响，除非 JS 主动移除属性 - 服务端直出时若未配
[hidden] { display: none !important; }，hydration 前可能闪现内容（FOVC），因为 CSS 尚未加载，但 DOM 已含hidden—— 此时浏览器仍按规范隐藏，只是部分旧版或极端定制内核可能延迟执行
hidden 对可访问性树和表单序列化的影响
渲染引擎同步将 hidden 元素从可访问性树（Accessibility Tree）中剔除，屏幕阅读器完全跳过；同时，该元素及其所有后代自动退出表单序列化链路——哪怕它有 name 和 value，也不会出现在 FormData 或 form.elements 中。
立即学习“前端免费学习笔记（深入）”；
这和 display: none 形成关键差异：
-
display: none下的<input name="email">仍会提交 -
hidden下同个<input name="email">在form.submit()或new FormData(form)中彻底消失 - 别混用
hidden和aria-hidden="true"：前者已切断整个子树的可访问性路径，后者冗余且可能在旧读屏中引发冲突
JS 控制 hidden 时最常卡住的点
开发者写 el.hidden = false 后元素仍不可见，90% 是因为之前手动设过 el.style.display = 'none'，而 el.hidden = false 并不会清空内联样式。渲染引擎此时面临冲突：CSS 内联规则优先级高于 [hidden] 选择器（除非你用了 !important），导致视觉上仍隐藏。
正确做法是：
- 显示前先清内联 display：
el.style.display = '' - 再设
el.hidden = false（自动移除属性） - 判断状态用
if (el.hidden)，别用el.hasAttribute('hidden')—— SSR 场景下属性可能已存在但 hydration 未完成，el.hidden是实时 DOM 状态 - 动画场景必须绕开
hidden：先el.hidden = false，再加opacity或max-height类触发 transition
真正容易被忽略的是：hidden 生效的前提，不是“有没有写对”，而是“有没有被更强的 CSS 规则压制”。哪怕只有一条 div#main { display: block !important; }，就能让整个子树的 hidden 失效——这不是 bug，是层叠规则的自然结果。
