toggle事件在Safari≤15.4或安卓WebView中存在不触发或延迟问题，属浏览器实现差异；应通过console.count和hasAttribute('open')验证，降级监听summary click，并确保监听器清理与状态读取准确。
toggle事件在Safari ≤15.4或安卓WebView中不触发或延迟
这不是代码写错了，而是浏览器实现差异：Safari ≤15.4 对 toggle 事件的派发有竞态延迟，部分安卓 WebView（如旧版X5内核）甚至完全不触发。仅靠 'toggle' in Event 特性检测无法识别运行时行为缺陷。
验证是否真失效，别只看 console.log —— 用 console.count('toggle fired') 确认调用次数；再加 setTimeout(() => console.log('open:', details.hasAttribute('open')), 0) 检查状态是否同步更新。
- 降级方案：对不支持或不可靠的环境，监听
summary的click事件，并手动切换details.open - 不要同时绑定
click和toggle—— 它们不是互备关系，混用会引发状态冲突 - 服务端可注入
data-toggle-supported="false"属性，JS 初始化时读取并选择监听策略
监听器重复注册导致“看起来延迟/多次触发”
组件重渲染（如 React/Vue）时，若没清理旧监听器，每次挂载都会新增一个 addEventListener('toggle', handler)，结果是第一次点击无响应（被后注册的覆盖？），第二次才生效，或日志输出翻倍。
- React 中必须在
useEffect返回清理函数：return () => el.removeEventListener('toggle', handler) - 原生 JS 动态插入
if (!el._toggleBound) { el.addEventListener('toggle', ...); el._toggleBound = true; } - 绝对不要在 render 函数或模板字符串拼接里直接写
el.addEventListener
状态读取时机错位：event.target.open 不可靠
toggle 事件触发时，event.target.open 理论上已是新值，但 SSR 渲染 + JS 补监听的场景下，DOM 更新可能尚未完成，直接读会拿到旧状态，尤其在 Safari 15.4 或某些 Android WebView 中。
- 最稳妥方式是读
details.hasAttribute('open')—— 它反映真实 DOM 属性，比布尔属性更稳定 - 若需在回调中操作子元素（如懒加载图片），用
requestAnimationFrame(() => { /* 此时 layout 已就绪 */ })替代setTimeout(..., 0) - 避免在 handler 里写
if (e.target.open) { ... }—— 这是 Safari 下埋点误判的主要来源
联动控制时手动设 open 导致状态竞争
手风琴效果（单开一栏）常见错误：在某个 details 的 toggle 回调里，直接写 otherDetails.open = false。虽然这能关掉其他栏，但 JS 设置不会触发它们的 toggle 事件，且若用户快速连点，可能因异步执行顺序导致状态错乱。
- 改用
otherDetails.removeAttribute('open')或otherDetails.toggleAttribute('open', false)，语义更清晰 - 加简单防抖：
if (this._isToggling) return; this._isToggling = true; setTimeout(() => this._isToggling = false, 100) - 所有联动操作完成后，统一用
requestAnimationFrame触发埋点，确保视觉与数据一致
真正难调的不是“怎么让 toggle 快起来”，而是“怎么让不同浏览器对同一交互给出一致的状态反馈”。状态读取、监听清理、降级路径，三者缺一不可。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
