直接用position: fixed + transform: translatex()可实现稳定弹出，但必须配合vw/vh单位、will-change: transform及菜单挂载至body下，否则ios/安卓webview易出现偏移、卡顿或z-index失效；移动端还需加touch-action: manipulation并确保触控热区≥44×44pt。
直接用 position: fixed + transform: translateX() 就能实现稳定弹出，但必须配合 vw/vh、will-change 和层级提级，否则 iOS/安卓 WebView 上大概率偏移、卡顿或被遮挡。
汉堡菜单从左侧滑入后位置偏移或不贴边？
根本不是动画写错了，而是 position: fixed 的基准点依赖视口（viewport），而某些安卓 WebView 或老版 Safari 会把地址栏高度算进视口，导致 top: 0 实际没顶到屏幕最上方。
- 改用
top: 0; left: 0; width: 100vw; height: 100vh;—— 不要用%，避免继承父容器缩放影响 - 给
html, body加height: 100%; overflow-x: hidden;，防止滚动条干扰宽度计算 - 若仍偏移，加
transform: translateZ(0);强制硬件加速并重置渲染层
用 transform: translateX() 替代 left 做滑入动画？
直接改 left 会触发 layout + paint，尤其在低端安卓机上卡顿明显；translateX() 只走合成器，性能好得多。但光换属性不够。
- 初始状态设
transform: translateX(-100%); - 激活状态设
transform: translateX(0); - 在菜单容器上加
will-change: transform;（仅需动画时加，别全局写） - 过渡写死：
transition: transform 0.35s cubic-bezier(0.34, 1.56, 0.64, 1);
点击后菜单不显示？大概率是 z-index 失效
很多开发者把 z-index: 9999 往菜单上一扔就以为完事，结果在 DevTools 里看到元素明明在 DOM 里，却“看不见”。实际是父容器（比如 <header></header>）有 overflow: hidden 或 transform，形成了新的 stacking context。
- 用 DevTools 检查菜单元素的
computed z-index是否为auto（说明没生效） - 往上逐级看父元素有没有
transform、opacity 、<code>filter、will-change—— 这些都会创建 stacking context - 把菜单提一级，挂到
下（配合 JS 动态append），绕过父级限制 - 确保
fixed容器的z-index高于所有可能遮挡它的元素（包括轮播图、弹窗、广告位）
移动端点击无响应？热区与 pointer-events 是关键
不是 JS 没绑，而是点击区域太小或被拦截。
- 给汉堡按钮的
<label></label>设display: block; width: 44px; height: 44px;（满足 iOS 最小触控 44×44pt） -
<input type="checkbox">被opacity: 0隐藏后，必须加pointer-events: none;，否则某些安卓 WebView 中会误触失效 - 别在
<label></label>外再套一层<div> 并试图监听 click —— 这会让 <code>:checked关联断开 - 移动端需加
touch-action: manipulation;防止延迟 300ms
真正难调的不是“怎么动”，而是“为什么不动”——偏移、卡顿、不可见、点不中，全在定位基准、渲染层、堆叠上下文和触控热区这四个地方卡住。每个都得单独验证，不能靠猜。
