抽屉与侧滑面板本质是不同交互模式：抽屉适用于临时模态内容，应基于dialog+inert实现语义化与可访问性；侧滑面板适合作为常驻布局的一部分，宜用CSS Grid/Flex响应式控制。
抽屉（Drawer）和侧滑面板（Sidebar）本质不是二选一
HTML 里没有原生 drawer 或 sidebar 元素——它们都是用 div + CSS 动画/定位 + JS 控制逻辑拼出来的交互模式。所谓“怎么选”，其实是问：在具体场景下，该用「抽屉式交互逻辑」还是「侧滑式布局结构」？关键看内容是否常驻、是否需响应式保底、是否要键盘/屏幕阅读器支持。
用 dialog + inert 实现语义化抽屉更稳妥
现代方案优先考虑语义与可访问性。原生 dialog 元素自带模态行为、焦点管理、Esc 关闭和 aria-modal="true"，比手写 div[role="dialog"] 少踩一堆坑。配合 inert 属性（或 polyfill）能真正禁用背景交互，避免手动遍历 DOM 加 tabindex="-1" 的错误做法。
常见错误现象：
– 点击抽屉外区域不关闭，或关闭后焦点丢失
– 屏幕阅读器仍可读取被遮盖的导航链接
– 移动端手势关闭时触发页面滚动
- 必须用
dialog.showModal()触发，而非仅靠display: block - 关闭时调用
dialog.close()，别只删 class - 侧滑动画用
transform: translateX()，别用left—— 否则会触发重排，动画卡顿 - 给
dialog设position: fixed和top: 0，否则在 iOS Safari 中可能错位
侧滑面板适合做永久性导航区，但得处理好断点逻辑
如果侧边栏是应用级导航（比如后台管理系统左侧菜单），它不该是“抽出来又收回去”的临时内容，而是布局的一部分。这时用 CSS Grid 或 Flex 布局 + @media 控制显隐更合理，而不是套抽屉逻辑。
立即学习“前端免费学习笔记（深入）”；
使用场景：
– 管理后台左侧菜单（桌面常驻，移动端折叠为按钮触发）
– 文档网站的目录锚点区（滚动联动，非模态）
- 别在移动端用
max-width: 768px硬切——应基于视口高度/宽度比、是否有 hover 能力（hover: hover）综合判断 - 折叠状态下的触发按钮必须有明确
aria-expanded和aria-controls - 用
prefers-reduced-motion查询禁用动画，否则运动敏感用户会不适 - 若用
transform: translateX(-100%)隐藏，记得加will-change: transform提升合成层，避免闪屏
Drawer 库选型要看是否侵入 DOM 结构
很多 UI 库（如 MUI、ShadCN）的 Drawer 组件默认把内容挂到 document.body 下，这会导致样式隔离失效、z-index 冲突、CSS 变量无法继承等问题。尤其当你用 CSS-in-JS 或 Shadow DOM 时，这种“飞出式”渲染极难调试。
性能影响：
– 每次打开都动态 append/remove 节点 → 触发重排
– 若内容含视频、Canvas 或 Web Component，卸载时可能未清理资源，造成内存泄漏
- 优先选支持
containerprop 的库（如 Radix UIDrawer允许指定挂载点） - 自己封装时，用
createPortal（React）或attachShadow（Web Components）控制作用域 - 避免在
Drawer内直接用useEffect请求数据——首次打开才加载，关闭后应保留状态，下次打开不重复请求
最易被忽略的点：键盘焦点环在抽屉内跳转时，Tab 键必须严格限制在抽屉内部，且关闭后焦点应回到触发按钮。这个逻辑几乎没人手动实现全，但 WCAG 2.1 是硬性要求。别依赖库的默认行为，务必实测。
