details标签本身不构成响应式布局，仅作为语义化交互容器，需配合CSS媒体查询和flex/grid等布局模型才能实现响应式；在移动端折叠导航中可零JS使用，但嵌套超过两层时Safari兼容性差，建议单层为主。
details标签本身不构成响应式布局
直接用 details 标签无法实现响应式布局——它只是个原生的、带展开/收起状态的交互容器，不具备栅格、弹性或断点控制能力。把它当“响应式布局方案”用，本质是混淆了「内容交互」和「视口适配」两个维度。真要做响应式，details 只能作为其中某个模块（比如移动端折叠导航、详情摘要）的语义化载体，必须配合 CSS 媒体查询和布局模型（如 flex 或 grid）才有效。
在移动端折叠导航中用details替代JavaScript
常见错误是写一堆 div + onclick + classList.toggle 来做汉堡菜单，既冗余又无障碍不友好。用 details 可以零 JS 实现语义化折叠：
- 外层
details包住整个导航列表，summary作为菜单按钮 - 导航项用
nav+ul写在details内部（不是summary里） - 桌面端用媒体查询把
details[open]强制展开，并隐藏summary；移动端保留默认行为 - 注意：Safari 15.4 之前对嵌套
details的toggle事件支持不稳定，单层就够了
示例关键片段：
<details class="mobile-nav">
<summary>☰ 菜单</summary>
<nav>
<ul>
<li><a href="/home">首页</a></li>
<li><a href="/about">关于</a></li>
</ul>
</nav>
</details>
details嵌套用于多级分类时的兼容性坑
想用 details 做三级分类导航？可以，但必须严格按规范嵌套，且注意 Safari 行为：
立即学习“前端免费学习笔记（深入）”；
- 合法结构只能是
details > summary + details > summary + ...，不能summary > summary（浏览器静默忽略第二层） - 超过 2 层嵌套时，iOS 15.4 以前的 Safari 可能漏触发某层的
toggle事件，导致状态不同步 - 视觉上容易缩进混乱，建议统一用
margin-inline-start控制每层缩进，别依赖嵌套层数自动撑开 - 整个
details树不能包在form里——旧版 Safari 会误把summary当表单控件，提交时带空值
自定义summary图标时别破坏可访问性
很多人用 summary::before { content: "▼" } 替换默认三角，但这是高危操作：
-
list-style: none+summary::before在 Safari 16.4 以下完全无效，且会移除原生::marker，键盘用户失去焦点提示 - 更稳妥的是只覆盖
summary::marker（仅 Safari 16.4+ 支持），并确保summary:focus-visible有清晰 outline - 安卓 WebView 中，粗暴移除 marker 可能导致点击热区缩小甚至失效，测试务必覆盖主流 WebViews
真正难的不是怎么写嵌套，而是判断哪一层该由用户手动展开、哪一层该默认打开——这取决于信息密度和设备输入方式，没有通用解，得实测。
