抽屉与侧滑面板本质是不同交互模式：抽屉适用于临时模态内容，应基于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 控制显隐更合理，而不是套抽屉逻辑。

Article To Html

文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。

下载

使用场景：
– 管理后台左侧菜单（桌面常驻，移动端折叠为按钮触发）
– 文档网站的目录锚点区（滚动联动，非模态）

• 别在移动端用 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，卸载时可能未清理资源，造成内存泄漏

• 优先选支持 container prop 的库（如 Radix UI Drawer 允许指定挂载点）
• 自己封装时，用 createPortal（React）或 attachShadow（Web Components）控制作用域
• 避免在 Drawer 内直接用 useEffect 请求数据——首次打开才加载，关闭后应保留状态，下次打开不重复请求

最易被忽略的点：键盘焦点环在抽屉内跳转时，Tab 键必须严格限制在抽屉内部，且关闭后焦点应回到触发按钮。这个逻辑几乎没人手动实现全，但 WCAG 2.1 是硬性要求。别依赖库的默认行为，务必实测。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！