纯html+css实现可靠汉堡菜单需：label加cursor: pointer并包裹可交互元素；input用position: absolute隐藏；菜单用max-height+overflow过渡；避免display:none；js仅补漏且须同步input.checked与aria-expanded状态。
怎么用纯 HTML + CSS 实现点击就展开的汉堡菜单
不能只靠 <input type="checkbox"> 和 label 配合 :checked 伪类，否则在 iOS Safari 上点一次没反应、点两次才生效——这是 Safari 对未聚焦元素的 click 事件拦截导致的。必须给 label 加 cursor: pointer，并确保它包裹了可交互区域（比如一个 span 或图标），否则部分安卓 WebView 会忽略点击。
常见错误现象：label 点击无反应、菜单闪一下就收起、iOS 上需双击才触发。
- 把
input放在label外部时，必须用for属性绑定id，且id值不能含特殊字符或空格 - 隐藏
input用position: absolute; left: -9999px，别用display: none或visibility: hidden，否则语义丢失且部分读屏器无法识别 - 菜单内容区（
nav或ul）用max-height+overflow: hidden做渐变展开，比单纯display切换更平滑
JavaScript 只补漏，不主控菜单状态
如果用了 JS 控制 aria-expanded 或切换 class，但没同步更新 input 的 checked 状态，会导致 checkbox 和视觉状态脱节——用户用键盘 Tab 进入再回车，菜单不动，但 input 已被勾选。
使用场景：需要支持键盘操作、配合屏幕阅读器、或菜单嵌套子菜单时必须用 JS 辅助。
立即学习“前端免费学习笔记（深入）”；
- 监听
change事件而非click，确保状态变更来自用户真实交互 - 手动设置
input.checked = true/false后，再更新aria-expanded，顺序不能反 - 避免在
touchstart里阻止默认行为，否则 iOS 上label关联失效
移动端真机测试绕不开的三个兼容点
Chrome DevTools 的“设备模拟”会骗人：它不模拟 Safari 的 focus 行为、不触发 Android Chrome 的 touch delay、也不还原微信内置浏览器对 pointer-events 的奇怪处理。
性能影响：用 transform: translateX(0) 触发硬件加速后，若菜单内有大量图片或复杂 SVG，iOS 15+ 会出现滚动卡顿。
- 微信 WebView 中，
position: fixed菜单在页面滚动后可能错位，得加will-change: transform强制重绘 - Android 旧版 UC 浏览器不支持
backdrop-filter，用半透明白色遮罩替代毛玻璃效果 - 所有动画用
transform和opacity，别碰height或margin，否则低端机掉帧明显
为什么不用第三方库（比如 Bootstrap 的 collapse）
Bootstrap 的 data-bs-toggle="collapse" 默认依赖 href="#target" 或 data-bs-target，但在单页应用里，# 锚点容易和路由冲突；而且它强制引入 bootstrap.js，哪怕你只用菜单，也会加载 Popper、Modal 等无关模块。
参数差异：原生方案中，菜单是否可关闭由 input 的初始 checked 决定；而 Bootstrap 需要调用 collapse('hide') 手动控制，耦合度更高。
- 如果你项目已用 Tailwind，直接写
peer-checked:translate-x-0比引入整个 Collapse 插件轻量得多 - Next.js / Remix 等服务端渲染框架中，JS 初始化时机不对会导致水合失败（hydration mismatch），纯 CSS 方案天然规避这个问题
- 真正难的不是做出来，是让「第一次点开」、「键盘 Tab 进入」、「屏幕阅读器朗读」、「横竖屏切换后保持状态」这四件事同时成立
