纯css下拉菜单hover失效主因是dom间隙导致状态中断及触屏不支持；标签页用:checked+radio实现需严格结构；:focus-within需容器可聚焦且有兼容性问题；纯css方案存在无障碍缺失、移动端失效等固有局限。
纯CSS下拉菜单为什么hover失效
原生无JS环境里，:hover 是唯一可用的交互伪类，但它的触发有硬性限制：只对鼠标悬停有效，且不支持触屏设备的“点击展开”。更关键的是，如果下拉项（.dropdown-menu）和触发元素（.dropdown-toggle）之间存在 DOM 间隙（比如 margin、border 或父容器 overflow: hidden），:hover 状态会立刻中断，菜单闪退。
- 确保触发元素与下拉容器是连续嵌套关系，中间不能有非父子层级的空隙元素
- 给父容器加
overflow: visible，避免被裁剪导致 hover 中断 - 移动端完全不可用——
:focus-within可作为备选，但需配合tabindex和键盘操作，不是“点一下就开”
标签页（Tabs）如何用:checked + <input type="radio">实现
这是无 JS 标签页最可靠的方式：利用单选按钮的互斥性和 :checked 伪类联动显示对应面板。核心在于每个 <input> 必须有唯一 name，且通过 id/for 关联标签，再用相邻/子元素选择器控制内容显隐。
-
<input type="radio" name="tabs" id="tab1">必须带name，否则无法互斥 - 标签页标题用
<label for="tab1"></label>，不能用<div onclick> —— 那需要 JS <li>面板内容需紧跟对应 <code><input>后（用~通用兄弟选择器）或包裹在同级容器内（用:checked ~ .panel） - 默认选中靠给第一个
<input>加checked属性，别指望 CSS 自动选中 - 若下拉由
<input>触发，把:focus-within放在 input 的父容器上，而非 input 自身 - Safari 旧版本（≤15.4）对
:focus-within在某些嵌套结构下有 bug，建议加降级：同时写:focus和:focus-within
:focus-within 在表单类下拉中的适用边界
当触发场景必须支持键盘导航（比如搜索框下拉建议），:focus-within 比 :hover 更合理，但它依赖整个容器获得焦点——意味着容器得有 tabindex="0"，且内部可聚焦元素（如 <input> 或带 tabindex 的 <div>）获得焦点时才生效。
<ul>
<li>不能直接写 <code>.dropdown:focus-within .menu { display: block; } 就完事——如果容器本身不可聚焦，永远不触发
性能与可访问性绕不开的代价
纯 CSS 实现的本质是用 CSS 规则模拟状态机，所有“展开/收起”逻辑都固化在选择器链里。这意味着：DOM 结构必须严格符合预期，任意改动（比如加个 wrapper div）可能让整个下拉失效；屏幕阅读器无法感知“菜单已展开”，因为没 ARIA 属性可更新。
立即学习“前端免费学习笔记（深入）”；
- 不要试图用
display: none+:hover控制复杂动画——浏览器重排开销大，且display切换会丢失 transition - 如果项目要求 WCAG 2.1 AA 级，纯 CSS 标签页必须手动加
role="tablist"、aria-selected等属性，而这些只能靠 JS 动态更新 - 最隐蔽的坑：CSS 选择器权重冲突。比如框架样式里写了
.dropdown-menu { display: none !important; }，你的:hover规则根本赢不了
真要零 JS，就得接受结构僵化、无障碍残缺、移动端体验归零——这不是技术限制，是模型本身的边界。
