抽屉菜单用 transform: translateX() 最稳
不用 left 或 margin-left 动画，因为它们会触发重排（layout），卡顿明显；transform 只影响合成层，GPU 加速，滑动顺。移动端尤其明显——哪怕只是 0.1s 的卡顿，用户也会觉得“菜单卡住了”。
常见错误是直接写 transform: translateX(-100%) 却没设父容器 overflow: hidden，结果菜单半截露在屏幕外，还可能被滚动条拉出来。
- 抽屉容器必须设固定宽度（比如
width: 280px），否则translateX(-100%)不知道 100% 是多少 - 父容器（通常是
<body>或一个 wrapper）要加overflow: hidden，否则页面仍可横向滚动 - 动画用
transform+transition，别用 JS 每帧改left
怎么让抽屉只在移动端生效
靠媒体查询控制开关状态，而不是靠 JS 判断设备类型。JS 判断容易出错（比如 iPad 横屏时 screen.width 超过 768，但仍是触屏设备），CSS 媒体查询更可靠、更轻量。
典型场景：桌面端菜单常驻顶部，移动端收进抽屉。这时候不能只靠 @media (max-width: 768px)，还要考虑横屏 iPad（max-height: 500px 之类）——但多数项目只需守住断点即可。
立即学习“前端免费学习笔记（深入）”；
- 抽屉默认
display: none，只在@media (max-width: 768px)里设为display: block - 抽屉的
transform初始值设为translateX(100%)（完全右出），打开时切到translateX(0) - 避免用
visibility: hidden替代display: none，它仍占布局空间，且无法阻止键盘焦点进入
transform 抽屉的焦点与可访问性陷阱
用 transform 移动元素，DOM 位置没变，所以屏幕阅读器仍会读取抽屉内容，即使它视觉上完全移出了屏幕。用户按 Tab 键时，焦点也可能跳进不可见的菜单项里——这是最常被忽略的一点。
错误做法是只靠 aria-hidden="true" 控制，却忘了同步管理 inert 属性或 tabindex。现代方案是组合使用：
- 抽屉关闭时，加
aria-hidden="true"并设inert（支持新浏览器）或手动遍历子元素加tabindex="-1" - 抽屉打开时，移除
aria-hidden，恢复可聚焦元素的tabindex（如有） - 务必在打开后把焦点移到抽屉第一个可聚焦元素（如
menu.focus()），否则键盘用户卡在按钮上出不去
真机上滑动冲突：iOS Safari 的“回弹”干扰
iOS Safari 默认允许页面在边界外拖拽（橡皮筋效果），当抽屉打开时，用户向右滑动可能触发整个页面回弹，导致抽屉看起来“抖一下”或意外关闭。这不是 bug，是系统行为，但体验极差。
解决思路不是禁用整个页面的 touchmove（会干掉所有滚动），而是精准拦截抽屉区域的横向拖动：
- 给抽屉容器加
touch-action: pan-y，允许上下滚动，禁止左右拖拽 - 如果抽屉内部有横向滚动组件（如轮播图），需在子元素上单独设
touch-action: pan-x - 慎用
overscroll-behavior: contain—— 它对抽屉本身无效，只作用于滚动容器，但可防止下拉刷新误触发
复杂点在于：抽屉打开时，body 仍可能响应 touchmove。稳妥做法是打开时给 <body> 加 touch-action: none，关闭时恢复。这点容易漏，一测真机就暴露。
