hidden 属性仅在同级兄弟节点且初始存在于 dom 时才避免重建；若用 innerhtml 替换则无效，且受 display: contents、css 覆盖、shadow dom 和框架动态渲染限制，实际性能取决于视图是否真正共存于 dom。
hidden 属性在 SPA 视图切换中真能省 DOM 开销？
不能直接省——它只在两个前提成立时才避免重建：源码视图和预览视图必须是同级兄弟节点，且初始就存在于 DOM 中。如果每次切换都用 innerHTML 替换整个容器内容，hidden 根本没机会生效。
- 错误做法：
editorContainer.innerHTML = '<div id="source-view">...</div>'→ 每次都销毁重建，hidden无从谈起 - 正确结构：父容器里静态存在
<div id="source-view"></div>和<div id="preview-view"></div>，仅靠el.hidden = true/false切换 - 必须检查祖先节点是否用了
display: contents—— 这个值会让hidden失效，浏览器直接忽略隐藏意图
为什么 el.hidden = false 有时不显示？
最常卡在这里：你以为只是“设个属性”，其实 hidden 受三重约束，缺一不可。
-
el.offsetParent === null是判断是否真正隐藏的可靠依据；若不为null，说明它还在渲染流里，大概率被 CSS 覆盖了 - 检查是否有
[hidden] { display: block !important; }或内联style="display: block"—— 这会直接绕过hidden的默认行为 - 若视图封装在 Shadow DOM 中（尤其是
closedmode），hidden可能被隔离，无法穿透边界生效 - 用 Lit、React 等框架动态生成模板时，如果写的是
${this.previewActive ? html`<div></div>` : ''}，DOM 根本没创建，hidden属性自然无处挂载
hidden 切换比 DOM 重建快在哪？又慢在哪？
快在跳过完整生命周期：不用解析 HTML 字符串、不触发 connectedCallback、不重新绑定事件监听器；但慢在每次赋值都会触发一次 layout（重排）。
- 快的部分：表单输入值、
scrollTop、Canvas 上下文、video.currentTime全部保留，无需手动同步 - 慢的部分：
el.hidden = true会立即导致浏览器重新计算布局，频繁切换（比如快速连点 tab）可能引发 layout thrashing - 注意：
hidden不支持 transition —— 给它加transition: opacity 0.2s完全无效，视觉上仍是硬切
SPA 中该不该用 hidden 控制多层预览？
不该。它本质是二值语义开关，不是状态控制器。多个预览层（草稿/发布/对比）需要共存+按需激活，hidden 会强制剔除非激活层，导致状态丢失。
- 替代方案：用
data-active+ CSS 类，例如[data-active="draft"] .preview-draft { display: block; } - 所有预览区块始终在 DOM 中，
input.value、滚动位置、Canvas 状态自动保留 - 配合
transition: opacity 0.2s, transform 0.2s可实现淡入+位移动效，hidden做不到 - 仅当需要向辅助技术明确声明“某层当前完全不适用”时，才在 JS 切换后补一句
el.hidden = !el.matches('[data-active]')，但别反过来驱动
真正影响性能的从来不是 hidden 属性本身，而是你有没有让两个视图真正“共存于 DOM”。只要结构不对，再怎么切 hidden 都是白忙活。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
