toggle事件不冒泡，需循环绑定每个details；动态新增须用MutationObserver或手动绑定；避免removeAttribute('open')触发二次toggle；scrollHeight计算需节流或缓存。
toggle事件不冒泡，批量监听必须用循环绑定
很多人以为给父容器监听 toggle 就能捕获所有子 details 的状态变化——不行。toggle 事件天生不冒泡，document.addEventListener('toggle', ...) 完全收不到。必须显式遍历每个 details 元素并单独绑定。
常见错误是每次 DOM 更新（比如 AJAX 插入新面板）都重新执行一遍 querySelectorAll('details').forEach(...)，导致重复绑定、内存泄漏。正确做法是：
- 只在初始化时绑定一次，后续动态插入的
details要手动调用绑定函数 - 或用
MutationObserver监听新增节点，仅对新出现的details绑定 - 避免在事件回调里再查
document.querySelectorAll——每次触发都重查 DOM，50 个面板就是 50 次 DOM 遍历
状态判断别依赖 event.target.open，它可能滞后
toggle 事件触发时，event.target.open 确实已更新，但如果你在回调里立刻操作兄弟节点，又紧接着触发另一个 toggle（比如手风琴逻辑中关闭其他项），某些旧版 Safari（15.4 之前）会出现状态不同步：刚设了 d.removeAttribute('open')，但它的 open 属性读出来还是 true。
更稳的方式是把状态“落地”后再处理：
立即学习“前端免费学习笔记（深入）”；
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 用
requestAnimationFrame延迟一帧再读取open值 - 或直接信任事件逻辑：只在
if (details.open)分支里做展开后动作，收起动作统一走removeAttribute('open')后的 DOM 变化响应 - 别在同一个事件里反复读写多个
details.open——先收集要操作的目标，再批量 set/remove
手风琴互斥时，避免 removeAttribute('open') 触发二次 toggle
这是最隐蔽的性能坑：d.removeAttribute('open') 在部分浏览器中会**再次触发 toggle 事件**，尤其是当该 details 当前是展开状态时。如果监听函数没做防护，就会形成递归调用，瞬间卡死页面。
必须加守卫条件：
- 只对当前非目标项执行
removeAttribute('open') - 在事件回调开头加
if (!event.target.hasAttribute('data-processed'))标记，处理完再设 - 更彻底的做法：用
detailsEl.toggleAttribute('open', false)替代removeAttribute，它不会触发新事件
大量折叠组件时，动画和 scrollHeight 计算要节流
如果页面有上百个 details，且你用了 JS + max-height 方案（比如为了兼容 Safari 15.3 或需要平滑动画），每次展开都要读 element.scrollHeight。这个操作强制同步回流，100 次就是 100 次 Layout，滚动会明显卡顿。
实际可优化点：
- 预估高度：对纯文本内容，按行高 × 行数估算，避开
scrollHeight - 缓存已测高度：用
Map存detailsEl → height，首次展开后存，后续复用 - 动画阶段不计算：收起时设
max-height: 0即可，无需测高；展开才需真实高度 - 如果只是控制显隐（不要动画），直接用原生
details+ CSSdisplay切换，比 JS 方案快一个数量级
