:focus-within能替代JavaScript控制下拉菜单，因其原生支持容器内任意子元素获焦即激活状态，兼顾鼠标悬停与键盘可访问性，避免仅用:hover或:focus导致的兼容问题。
focus-within 为什么能替代 JavaScript 控制下拉菜单
因为 :focus-within 是原生 CSS 伪类，只要容器内任一子元素获得焦点（比如用户 tab 到 <button></button> 或点击后聚焦到 <input>、<a></a>），整个父容器就匹配该状态——这正好覆盖「鼠标悬停+键盘可访问」的双重要求，不用写 JS 监听 click 或 blur 事件。
常见错误现象：只用 :hover，导致键盘用户无法打开菜单；或用 :focus 绑在触发按钮上，但菜单展开后焦点移入菜单项时，按钮失焦，菜单立刻收起。
-
:focus-within必须作用于包含触发器和菜单项的共同父容器（通常是<nav></nav>或<div class="dropdown">） <li>菜单内容需是该父容器的**后代元素**，不能用 <code>position: absolute脱离文档流后丢到 body 底部 - IE 完全不支持，Edge 79+ 才支持；如需兼容旧版，得回退到 JS 方案
- 推荐方案：用
max-height过渡，设一个足够大的上限值（如max-height: 500px），初始为max-height: 0，展开时设为500px - 配合
overflow: hidden防止内容溢出，否则动画期间能看到裁剪边缘 - 避免用
opacity单独过渡，它不占布局空间，会导致下方内容跳动 - 过渡时间建议 0.2s–0.3s，太慢显得迟滞，太快像闪现
- 确保所有可交互菜单项（
<a></a>、<button></button>）默认可聚焦（即不设tabindex="-1"，除非你手动管理焦点流） - 不要给菜单容器本身设
tabindex，它只是状态载体，不是焦点目标 - 如果菜单里有搜索框等需要初始聚焦的元素，用 JS 在
:focus-within触发后.focus()，纯 CSS 无法做到 - 给触发按钮加
touch-action: manipulation减少延迟 - 避免同时监听
click和:focus-within，否则 JS 强制展开 + CSS 自动收起会冲突 - 真机测试必做：用 Safari 开发者工具远程调试 iOS，看
document.activeElement是否正确落到菜单内 - 若问题顽固，可在移动端降级为
:hover+clickJS 切换 class，保留无障碍语义（如aria-expanded）
transition 怎么让 height 变化有动画效果
直接对 height 做 transition 会失效——因为从 height: 0 到 height: auto 无法插值。必须用可计算的值，或换用其他可过渡属性。
使用场景：菜单高度不固定（含响应式文字、多行链接），不能写死 height: 200px。
立即学习“前端免费学习笔记（深入）”；
菜单收起时如何避免“闪一下”或焦点丢失
焦点离开触发器但仍在菜单内时，菜单应保持展开；只有当焦点彻底离开整个下拉区域（包括菜单项），才收起。否则用户用键盘 tab 浏览菜单时，刚 tab 到第二项就消失。
容易踩的坑：给菜单项加 tabindex="-1" 后没处理好初始聚焦逻辑，导致首次键盘操作无法进入菜单。
移动端点击穿透与 focus 状态残留问题
在 iOS Safari 和部分安卓浏览器中，点击触发器后，:focus-within 可能短暂生效又立刻消失，导致菜单闪退；或者轻触后焦点未真正落在菜单项上，造成“点开了却无法用键盘继续操作”。
根本原因：移动端 click 事件延迟、focus 行为不一致，以及 :focus-within 依赖真实焦点而非模拟状态。
最麻烦的其实是焦点管理边界——CSS 能控制显隐，但没法决定焦点该落在哪、何时转移、是否循环。这部分一旦忽略，键盘用户就卡在半路。
