hidden 属性不销毁 DOM 节点但影响渲染路径：display: none 跳过布局、无渲染对象；visibility: hidden 完整布局绘制但不输出像素；三者均保留在 DOM 树中，document.getElementById() 始终有效。
hidden 属性本身不直接影响内存占用，真正决定 DOM 节点是否被浏览器“轻量处理”的，是它触发的渲染路径——而 display: none 会直接跳过布局计算，visibility: hidden 则仍参与布局、绘制准备，只是最终不画出来。
hidden 和 display: none 都不销毁 DOM 节点，但浏览器对它们的“计算开销”不同
三者（hidden、display: none、visibility: hidden）都不会让 document.getElementById() 返回 null，节点始终在 DOM 树中。区别在于后续流程：
-
hidden：浏览器仍执行 layout（布局）、paint（绘制）准备，但跳过无障碍树暴露，并可能抑制部分绘制逻辑；JS 可正常调用getBoundingClientRect()，返回值有效 -
display: none：节点直接从渲染树剔除，layout 阶段就不再计算其尺寸、位置、子树；getBoundingClientRect()返回全零对象，offsetParent为null -
visibility: hidden：节点完整走完 layout 和 paint 准备，只是最终像素不输出；getBoundingClientRect()正常，且父级visibility: hidden下，子元素设visibility: visible仍可显示
频繁显隐时，display: none 的重排（reflow）成本更高
切换 display 值（如 block ↔ none）必然触发 reflow，因为浏览器要重新构建渲染树并计算所有受影响节点的几何信息；而 visibility 切换只触 repaint，开销小得多——尤其适合动画或高频交互场景。
- 表格行（
<tr>）批量隐藏/显示，用visibility: hidden比display: none更稳，避免整表重排抖动 - 使用
hidden属性配合 CSS[hidden] { opacity: 0; transition: opacity 0.2s; }，能实现渐变隐藏，但底层仍走 layout —— 不如visibility+opacity组合轻量 - 若用 JS 频繁 toggle
display，建议缓存节点引用并批量操作，避免连续强制同步 layout
内存里真正“省”的不是 DOM 节点，而是渲染中间状态
DOM 节点对象本身内存占用几乎一致；差异来自浏览器内部缓存：
立即学习“前端免费学习笔记（深入）”；
-
display: none节点不会生成对应的渲染对象（RenderObject），也不存 layout 数据，GPU 渲染队列里无其指令 -
visibility: hidden节点仍保有完整 RenderObject 和 layout 结果，只是绘制阶段标记为“跳过” -
hidden行为因浏览器实现略有差异：Chromium 中接近visibility: hidden路径，WebKit（Safari）某些版本会更激进地跳过部分 layout 计算，但不保证
真正该关心的不是“内存多几 KB”，而是你是否需要子元素独立控制显隐、是否依赖 getBoundingClientRect()、是否要支持屏幕阅读器正确播报——这些决定了该选哪条路径，而不是盯着内存数字做决策。
