非渲染元素仍存在于dom中，拖慢解析、干扰表单、影响可访问性；真正优化应删除“永远不显示”的节点，而非仅隐藏。
非渲染元素（如 display: none、hidden、visibility: hidden）不是“看不见就等于不存在”——它们仍在 DOM 中、参与样式计算、拖慢解析、干扰表单逻辑，甚至让屏幕阅读器误读。想靠隐藏来“优化”，反而埋下性能与可访问性双坑。
为什么 display: none 的节点仍会拖慢首屏渲染
浏览器解析 HTML 时，每个标签都生成 DOM 节点；即使设了 display: none，该节点仍被构建、继承样式、匹配选择器、占用内存。尤其当它出现在 SSR 输出的首屏 HTML 中（比如未登录态的用户菜单模板），解析耗时直接增加——实测 200 个 display: none 的 <div> 可使 DOM 构建延迟 40–60ms。
<ul>
<li>它不触发 paint，但会触发 style recalc：CSSOM 仍需为它推导 computed style，哪怕最终丢弃</li>
<li>父容器是 <code>flex 或 grid 时，隐藏一个子项会强制重算整个容器布局分配
document.querySelectorAll('.item') 仍包含它，遍历成本不变v-if/v-show 混用，v-show（即 display: none）在组件挂载后仍保留节点，而 v-if 才真正销毁
hidden 属性在表单和无障碍场景下的真实行为
hidden 不是视觉开关，而是语义开关：它告诉浏览器“这个元素当前不参与任何流程”。但它生效有硬前提——节点必须静态存在于 DOM，且未被 CSS 覆盖或 Shadow DOM 隔离。
- 表单中：
new FormData(form)完全忽略hidden元素，form.elements列表里也查不到它；而display: none的 input 仍会被序列化、校验、提交 - 屏幕阅读器跳过
hidden元素，但不会跳过visibility: hidden或opacity: 0（除非额外加aria-hidden="true"） - 切换时写
el.hidden = false不保证显示：检查el.style.display是否残留'none'，若有需手动el.style.removeProperty('display') - Safari iOS 9.3+ 才完整支持；老版本需 fallback 到
display: none+ 清空value和移除required
哪些“隐藏”该删，而不是留着
真正该从 HTML 中物理删除的，是那些“永远不显示”的节点。藏在 display: none 下面，只是给浏览器多添一道解析负担。
- 权限控制类内容：未登录时的
<nav class="user-menu"></nav>、无权限时的编辑按钮——SSR 时就不该输出，而非靠 JS 或 CSS 隐藏 - 多语言占位符：CMS 自动生成的
<div lang="ja" style="display:none">…，若当前 locale 是 <code>zh-CN，整块结构应剔除 - 旧版兼容占位：如为 IE11 写的
<div id="ie-fallback" style="display:none">…，现在可直接删 <li>动态组件的空模板：Vue 的 <code><template v-if="false"></template>若永远不满足条件，不如删掉整段模板 - Safari ≤15.4 完全不识别，回退为
display: block，导致布局错乱 - 父元素用了
table-layout: fixed，子元素设display: contents会让列宽失效 - 在
<tr> 或 <code><td> 内部使用，会破坏表格语义，浏览器可能自动补全 <code><tbody> 或拆解节点 <li>DevTools Elements 面板里看不到子元素“升层”，但 Layers 面板能验证：合成层数量应明显减少；若没变，说明没生效</li> <p>最易被忽略的一点：删除一个 <code>display: none的节点，比加一条hidden属性更能降低内存峰值——因为浏览器不用再为它维护 layout state。别把“隐藏”当优化，先问一句：它真有必要存在吗？
用 display: contents 替代 wrapper 的实际限制
display: contents 让父节点“视觉消失”，子元素直接受上级 flex/grid 控制，是清理冗余嵌套的利器——但它不是 CSS reset，失效场景非常具体。
