display: none 会让屏幕阅读器完全忽略元素，因其跳过渲染和可访问性树构建；dom 节点虽在，但辅助技术无法读取、焦点也无法进入。
display: none 为什么会让屏幕阅读器完全忽略元素
它不只是“看不见”，而是让浏览器直接跳过该元素的渲染和可访问性树构建。DOM 节点还在，但辅助技术根本读不到、焦点也进不去。
常见错误是用 display: none 隐藏表单提示文字或图标旁的说明文本——结果键盘用户 tab 到按钮时，屏幕阅读器报不出完整语义，只说“提交”，没上下文。
- 适合场景：
v-if控制的模态框、未登录时不渲染的个人中心入口、纯临时占位内容 - 不适用场景：需要为屏幕阅读器提供额外说明的图标按钮（比如仅含
📨的通知图标）、SEO 关键文本、跳过链接 - 性能注意：频繁切换
display: none会触发重排（reflow），动画中不能用 transition 过渡
hidden 属性比 display: none 更语义化，但要注意覆盖风险
hidden 是 HTML5 原生布尔属性，语义明确：“这个内容当前无关”。浏览器默认行为等同于 display: none，但它不依赖 CSS，也不受类名污染。
容易踩的坑是写了 [hidden] { display: block; } 这类全局样式——一旦存在，hidden 就失效了。这不是 bug，是规范允许的层叠逻辑。
- JS 控制最简方式：
el.hidden = true/el.hidden = false，比切 class 更直接 - 兼容性：IE9 及更早不支持，但现代项目基本无需 polyfill
- 与
aria-hidden不要混用：如果同时写<div hidden aria-hidden="true"></div>，后者冗余；若想兼容旧读屏，可加但非必须
visibility: hidden 和 opacity: 0 对键盘用户的实际影响不同
visibility: hidden 元素仍占布局空间、仍能被 tab 键聚焦（只是看不见光标），容易造成“卡焦点”现象；opacity: 0 元素则完全透明但默认仍响应点击和 focus，需手动加 pointer-events: none 才安全。
这两者都不该单独用于隐藏交互控件。比如一个用 visibility: hidden 隐藏的 <button></button>，键盘用户按 tab 会停在空白处，然后困惑地发现“焦点丢了”。
-
visibility: hidden适合保留布局结构的过渡占位（如加载中骨架图） -
opacity: 0+pointer-events: none才算真正“视觉隐藏+交互屏蔽”，可用于淡入动画起点 - 两者对 SEO 均无负面影响，搜索引擎仍能抓取内容
sr-only 类不是“隐藏”，而是“仅对屏幕阅读器可见”
所谓 .sr-only，本质是一组 CSS 规则（如 position: absolute; left: -9999px;），目的是把文字推到视口外，视觉不可见，但屏幕阅读器照读不误。
它和 display: none 完全相反：前者牺牲视觉可见性保可访问性，后者牺牲可访问性保视觉简洁。别把 .sr-only 当成通用隐藏方案——它专为“视觉冗余但语义必需”的内容设计。
- 典型用途：图标按钮的
<span class="sr-only">删除</span>、表单必填字段的星号说明、跳过链接文案 - 别套在
<div hidden> 上：语义冲突，且可能被 CSS 覆盖失效 <li>不要用 <code>font-size: 0或color: transparent替代：部分读屏软件会跳过或误读
真实项目里最容易被忽略的，是同一份 DOM 同时承载多种隐藏意图：比如一个折叠面板，初始状态要用
hidden 或 display: none 彻底移除，展开后需管理焦点、同步 aria-expanded，而面板标题里的小图标又得靠 sr-only 补充语义——这些不能靠一种 CSS 属性一劳永逸。
