真正可用的侧边栏抽屉动画组合是 visibility + transform，opacity 仅作遮罩层辅助；因 visibility + opacity 无法触发可靠过渡、不阻断点击穿透、不隔离焦点，且破坏可访问性。
直接用 visibility + opacity 实现侧边栏抽屉，动画会卡顿、点击能穿透、键盘焦点仍可进入——这不是“能动”，而是“动得有问题”。真正可用的组合是 visibility + transform，opacity 只能当辅助，不能当主控。
为什么 visibility + opacity 不能单独做抽屉动画
很多人试过写这样的 CSS：
.drawer {
visibility: hidden;
opacity: 0;
transition: opacity 0.3s, visibility 0.3s;
}
.drawer.open {
visibility: visible;
opacity: 1;
}
结果发现：动画不触发、关闭后还能点到背后按钮、Tab 键照样跳进抽屉里。原因很实在：
-
visibility: hidden本身不触发动画，transition对它无效，除非显式声明时长（但即使写了，浏览器也不保证过渡帧） -
opacity变化不影响可访问性：屏幕阅读器照读，Tab焦点照进，pointer-events默认仍为auto - 只靠透明度变化，抽屉 DOM 仍在原位占空间，遮罩层对齐、z-index 层级都容易错乱
visibility + transform 才是可靠起点
抽屉容器必须同时满足三件事：视觉隐藏、焦点隔离、GPU 加速位移。这三件事只能靠 visibility 和 transform 分工完成：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 初始状态设为
visibility: hidden; transform: translateX(-100%)——-100%按自身宽度算，稳 - 展开时切 class：
visibility: visible; transform: translateX(0) -
transition必须明确写两段：transition: visibility 0.3s, transform 0.3s ease-in-out；不能只写transition: all，否则可能意外过渡color或background - 别用
display: none初始化，它会让transition直接失效，且破坏aria-hidden的语义连贯性
opacity 可以加，但只能加在遮罩层上
opacity 不适合控制抽屉本体，但它对遮罩层（overlay）非常友好：
- 遮罩层用
div.overlay，固定定位覆盖全屏，background: rgba(0,0,0,0.5) - 它的
opacity可以从 0 → 0.5 过渡，配合visibility: hidden → visible，既平滑又安全 - 抽屉本体绝不要用
opacity控制显隐——它不阻止点击穿透，也不影响焦点流，纯属“假装隐藏” - 如果真想让抽屉带淡入效果，把
opacity加在抽屉内部内容区（比如.drawer__content），而不是整个.drawer
容易被忽略的焦点与滚动锁定细节
哪怕 CSS 动画写对了，用户一按 Tab 或滚轮，体验立刻崩坏。这些不是“锦上添花”，是硬门槛：
- 抽屉打开时，必须同步给
<body>加overflow: hidden，否则 iOS Safari 会允许页面横向滚动 - 主内容区要加
aria-hidden="true"，抽屉加aria-modal="true" tabindex="-1" - 抽屉展开后，得等
transitionend事件触发，再手动focus()到第一个可聚焦元素（如关闭按钮） - 按
Escape关闭时，焦点必须回到触发按钮，否则键盘用户会卡在空白处
抽屉最难的部分从来不是“怎么滑出来”，而是“滑出来之后，用户能不能像操作原生对话框一样继续用键盘和屏幕阅读器”。visibility 和 transform 是基础支撑，但焦点管理、aria 属性、inert（或等效手动处理）才是决定它能不能上线的关键。
