hidden 属性在虚拟 dom diff 中不参与对比，但会强制触发 layout，因其是浏览器原生接管的语义指令而非响应式状态；vue/react 均在 patch 后直接操作 el.hidden 或 setattribute，绕过 diff 流程，导致无法优化、ssr 易错位、layout 开销高。
hidden 属性在虚拟 DOM 对比中不参与 diff，但会强制触发 layout —— 它不是“状态”，而是“语义指令”，框架无法优化掉它的副作用。
Vue/React 中 hidden 不会被 patch 算法处理
虚拟 DOM 的 diff 过程只对比可变的属性（如 class、style、id）和事件监听器；hidden 是布尔属性，一旦存在即生效，且浏览器原生接管，框架不会把它当作“需要同步的响应式字段”。
- Vue 模板里写
<div :hidden="showPreview">，实际生成的是 <code>el.hidden = false或el.setAttribute('hidden', '')，这步发生在 patch 后的 commit 阶段，不走 vdom diff - React 中
<div hidden="{showPreview}"> 会被编译为 <code>el.hidden = showPreview，同样绕过 fiber 节点的 props diff 流程 - 这意味着：哪怕你用
key强制重用节点，hidden的切换仍会引发 layout，框架无法合并或跳过 -
hidden触发 reflow：offsetHeight、getBoundingClientRect()等读取会强制同步 layout - 同级多个
hidden元素同时切换（比如编辑器的源码/预览/调试三视图），layout 开销呈线性增长 - 若父容器用了
display: contents或在 Shadow DOM closed 模式下，hidden失效，但框架仍会执行赋值 —— 白跑 JS，还可能掩盖结构问题 - Next.js / Nuxt 等框架默认不注入兜底 CSS，需手动在
_document.tsx或全局样式中补上 - Hydration 前检查
el.hasAttribute('hidden')并与当前状态对齐，比依赖el.hidden更可靠（因为 SSR 渲染后el.hidden可能为false，但属性仍在） - 使用
data-active+ CSS 类替代hidden，可让 SSR 和 CSR 的渲染逻辑完全一致，规避 hydration 错位
hidden 的 layout 开销比 class 切换高得多
设 el.hidden = true 时，浏览器必须立即从渲染树中剔除该分支并重新计算布局；而 classList.toggle('is-hidden') 只需更新样式层，若 CSS 使用 opacity 或 transform，甚至能避免 layout。
SSR hydration 时 hidden 容易导致首屏错位
服务端已渲染 <div id="preview" hidden>，但客户端 JS 加载前，若未提前注入 <code>[hidden] { display: none !important; }，浏览器会先显示内容再隐藏，造成闪现；hydration 后若状态不一致（比如服务端 hidden，客户端初始 el.hidden = false），还会触发额外 layout。
真正难处理的不是怎么写 hidden，而是它一旦生效，就绕过了所有框架的优化路径 —— layout 不可避，diff 不感知，SSR 和 CSR 的行为边界也更模糊。用之前得先确认：你是否真的需要语义层面的“不相关”，而不是视觉层面的“暂时不见”。
