details元素默认应收起，仅在必要时加open属性；语义化首选details而非CSS切换；需关注兼容性、动画、SEO、状态持久化及无障碍细节。
折叠元素默认应该收起还是展开？
取决于用户意图和内容重要性，没有绝对规则。但绝大多数场景下，details 元素默认应保持收起（即不加 open 属性），因为折叠的本意就是减少初始信息密度。强行默认展开会削弱折叠价值，也违背可访问性原则——屏幕阅读器会把 details 当作可交互控件，预期用户主动触发。
例外情况：当折叠块是唯一操作入口（如表单提交前的「高级选项」），且业务要求用户必须查看时，才考虑加 open。但此时要同步确保键盘 Tab 可聚焦、Enter 可切换，并测试移动端点击热区是否足够大。
用 details 还是手写 display: none 切换？
details 是语义正确、开箱即用的方案；手写 CSS + JS 控制只在需要深度定制动画或兼容 IE 时才必要。但注意：details 的 summary 标签无法被 label 关联，也不能直接绑定 for 属性；若需与表单控件联动（比如「展开后勾选此项」），就得退回到手写方案。
常见错误现象：details 在 Safari 旧版本中不支持 toggle 事件，监听 toggle 前必须先检查 'ontoggle' in document.createElement('details')；否则 JS 报错导致后续逻辑中断。
立即学习“前端免费学习笔记（深入）”；
- 需要平滑过渡动画？
details本身不支持transition，得靠max-height或height模拟，此时手写更可控 - 需要支持 IE？必须放弃
details，改用aria-expanded+aria-controls手动管理状态 - 是否要 SEO 友好？
details内容默认会被搜索引擎索引，无需额外处理；而display: none的内容可能被降权
折叠状态如何持久化（刷新后保持）？
浏览器不自动保存 details 的 open 状态，必须手动存取。推荐用 localStorage 记录每个 details 的 id 或数据属性值，而非 DOM 索引——因为 DOM 顺序可能随渲染变化。
实操要点：
- 给
details加唯一id或data-collapse-id，例如<details data-collapse-id="filter-panel"> - 在
toggle事件回调里读取event.target.open，存入localStorage.setItem('collapse:filter-panel', event.target.open) - 页面加载后遍历所有
details[data-collapse-id]，根据localStorage值调用el.open = JSON.parse(...)（注意类型转换） - 避免在服务端渲染（SSR）页面中直接设
open属性——这会导致水合 mismatch，React/Vue 中应统一由 JS 控制
无障碍（a11y）最容易漏掉的三件事
折叠组件不是加个 aria-expanded 就算完事。真正影响可用性的细节藏在交互链路里：
-
summary必须可键盘聚焦（默认支持），且按Space或Enter能触发切换——不要用div+click模拟，那会丢失原生行为 - 展开后，焦点不应停留在
summary上，而应移到新显示内容的首个可聚焦元素（如第一个input或带tabindex="0"的容器），否则视障用户会“掉进空白” - 如果折叠内容含表单，提交后要重置
open状态并清除localStorage缓存，否则用户下次进来仍看到上次未完成的表单，易引发误操作
复杂点往往不在折叠本身，而在它嵌套在导航、模态框、多步骤表单里时的状态同步——比如一个折叠面板同时被路由参数、URL hash 和用户偏好控制，这时候优先级和冲突处理逻辑比实现折叠更费神。
