不是必须，但<details>和<summary>是唯一原生支持语义化、无障碍、无需JS即可展开/折叠的方案；多级结构应将子<details>置于父<details>的<div>内容区而非嵌套在<summary>中，靠CSS缩进而非DOM嵌套实现视觉层级。
手风琴菜单必须用 <details> 和 <summary> 吗？
不是必须，但这是唯一原生支持语义化、无障碍、无需 JS 就能展开/折叠的方案。用 <div> + JS 模拟虽然灵活，但默认不暴露展开状态给屏幕阅读器，<details> 会自动映射 aria-expanded 和 aria-controls，省掉大量可访问性补丁。
常见错误是把多个 <details> 套在一起试图实现“多级”——浏览器不支持嵌套 <details> 的交互逻辑（子 <details> 不会随父级关闭而收起），也不推荐在 <summary> 里放按钮或链接（会干扰点击区域）。
多级结构怎么写才合法又可用？
HTML 标准不允许 <details> 直接嵌套，但允许在 <details> 的 <div> 内容区里再放一个独立的 <details>。关键点是：每一级都必须是顶层 <details> 元素，靠 CSS 控制缩进和视觉层级，而非 DOM 嵌套关系。
-
<details>必须有且仅有一个<summary>作为第一个子元素 - 子级
<details>放在父级<details>的<div>（或其他块级容器）内部，不能放在<summary>里 - 避免用
display: none隐藏子级内容——这会破坏语义和可访问性；应依赖<details>自身的隐藏机制
<details>
<summary>一级菜单</summary>
<div>
<details>
<summary>二级菜单</summary>
<p>二级内容</p>
</details>
</div>
</details>
为什么 CSS 缩进比 JS 控制更可靠？
用 JS 动态切换 class 或内联 style 来控制显示/隐藏，容易和 <details> 的原生行为冲突（比如 JS 强制 display: block 但用户已手动关闭，状态不同步）。CSS 层级只需聚焦两件事：视觉缩进 + 控制子级初始隐藏状态。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- 用
margin-left或padding-left实现缩进，别用绝对定位或transform——会影响焦点顺序和屏幕阅读器遍历 - 子级
<details>默认就是关闭状态，不需要额外 CSS 隐藏；若需默认展开，加open属性即可 - 不要用
:not([open])去隐藏整个<details>——这会覆盖原生折叠逻辑，导致无法点击展开
移动端点击穿透和 focus 管理容易被忽略
<summary> 在 iOS Safari 上有 300ms 延迟，且点击区域小，容易误触。另外，键盘用户按 Tab 进入 <summary> 后，Enter/Space 才触发展开，但很多人不知道这个交互模式。
- 给
<summary>加padding（至少 16px）扩大点击热区，别只靠文字大小撑开 - 避免在
<summary>里加<button>——会导致双击事件或焦点跳转异常 - 如果菜单项本身是链接，把
<a>放在<summary>外层<div>里，而不是包裹<summary>，否则点击链接会同时触发展开
真正麻烦的是多级联动：父级收起时，子级不会自动关闭，得靠 JS 监听 toggle 事件手动处理——但这已经脱离了“基础语义结构”的范畴，属于增强行为，先确保原生功能跑通再说。
