用:checked伪类替代:hover可实现移动端可控的点击展开/收起菜单，需将checkbox与菜单置于共同父容器内、菜单设position:absolute且父容器设position:relative，配合max-height过渡动画，并完善可访问性。
用 :checked + <input type="checkbox"> 替代 hover 实现点击展开
纯 CSS 悬浮菜单靠 :hover 实现，但移动端不触发 hover，且用户常误点即收起。改用 :checked 伪类配合隐藏 checkbox，能真正实现“点一下展开、再点一下收起”，行为更可控。
关键不是“模拟 hover”，而是把菜单状态绑定到 checkbox 的选中态上：
-
<input type="checkbox">必须放在菜单触发元素（如按钮）和菜单容器的共同父容器内，否则无法用兄弟选择器~或相邻选择器+控制菜单显示 - 触发按钮不能是
<label></label>包裹 checkbox 的那种“伪装点击”，而应直接操作 checkbox——否则 iOS Safari 可能不触发:checked重绘 - 菜单容器需设
position: absolute，且父容器必须有position: relative，否则定位会脱出预期区域
position: absolute 菜单定位偏移经常错位？检查这三处
菜单看起来“飞走了”，大概率不是 top/left 值写错，而是定位上下文没理清。
- 菜单的最近一个非
static定位祖先元素才是它的position: absolute参照物；如果忘了给外层加position: relative，它就会一路往上找，最终相对<body>定位 -
top: 0不等于“贴着触发按钮下方”，它贴的是参照容器的顶部；想对齐按钮底部，得用top: 100%，再加margin-top: 4px避开间隙 - 若触发按钮是 flex 或 grid 子项，其自身
position: relative可能被父容器的对齐属性（如align-items: center）干扰，导致菜单垂直偏移——此时建议菜单容器用transform: translateY(4px)微调，比硬调 top 更稳定
为什么不用 :focus-within 或 details/summary？
这两个方案看似更语义化，但实际落地时坑不少：
立即学习“前端免费学习笔记（深入）”；
-
:focus-within在移动端键盘唤起后容易意外失焦收起菜单，尤其表单内嵌菜单时；且 Safari 对:focus-within在动态插入内容中的支持仍不稳定 -
<details>默认有 outline 和 focus 样式，覆盖成本高；更重要的是，它不支持“点击空白处收起”——必须点 summary 才能关闭，交互不符合多数下拉菜单预期 - 两者都无法精确控制过渡动画的触发时机：
:checked可以配合max-height+overflow: hidden做高度渐变，而details的 open 状态切换是即时的，加 transition 无效
移动端点击穿透、键盘遮挡、滚动异常怎么防？
菜单在手机上展开后，常出现点不到选项、输入框被遮住、页面滚动卡顿等问题，根源不在样式本身，而在交互层缺失约束：
- 菜单展开时，给
<body>加overflow: hidden，防止背景滚动；但别只写overflow: hidden，要补上touch-action: none，否则 iOS 上仍可能触发弹性滚动 - 菜单内若有
<input>，展开瞬间焦点自动跳入会导致键盘顶起菜单——应在:checked触发后用 JS 延迟.focus()，或干脆禁用自动聚焦 - 避免用
height: auto配合 transition：CSS 无法过渡 auto 值。改用max-height（设一个足够大的值如500px），并确保菜单内容不超过该值，否则裁剪
id 和对应 label[for]，屏幕阅读器就无法告知用户“这是个可切换的菜单”。这不是锦上添花，是菜单能否被正常使用的分水岭。 
