summary 本身不引发重排重绘，但不当嵌套或错误监听会放大性能问题；应使用 toggle 事件、延迟加载内容、增大移动端热区并保障语义完整性。
summary 标签本身不触发重排重绘，但不当嵌套或监听方式会拖慢交互响应——它不是性能瓶颈，而是性能放大器。
为什么点击 summary 有时卡顿？
卡顿通常不是 summary 或 details 自身导致的，而是展开后 DOM 突然加载大量内容（比如未懒加载的图片、未节流的 JS 初始化）引发的渲染压力。
- 常见错误：在
details内部直接放完整表格、长列表或iframe，且未做任何延迟加载 - 真实场景：FAQ 页面每个
details包含 5 张高清图 + 3 个第三方组件初始化脚本 - 性能影响：Chrome DevTools 的 Rendering 面板中可观察到 Layout → Paint 阶段明显拉长，尤其在低端 Android 设备上
- 解决思路：只在
open状态下才加载关键资源，用details[open]CSS 选择器控制显示逻辑，而非单纯靠display: block
summary 与 JavaScript 的 toggle 事件怎么写才不翻车？
别监听 click，用原生 toggle 事件——它只在用户手动点击 summary 时触发，且能准确反映状态变更，避免和程序化设置 open 属性冲突。
DeepBI DHTML 页面生成器
下载
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
- 错误写法：
summary.addEventListener('click', () => details.open = !details.open)，会绕过浏览器内置状态同步，破坏可访问性 - 正确写法：
details.addEventListener('toggle', (e) => { if (e.target.open) { /* 开始加载内容 */ } }) - 注意点：该事件不冒泡，不能委托；IE 完全不支持，Safari 15.4+ 才稳定，需降级 fallback（如监听
details的attrmodified不现实，建议用MutationObserver监听open属性变化）
如何让 summary 在移动端更易点中？
移动端默认点击热区太小，尤其在折叠状态下仅显示文字加一个小三角，容易误触或点不中。
立即学习“前端免费学习笔记（深入）”；
- 必须加
padding：至少padding: 12px 16px，避免紧贴文字边缘 - 禁用默认三角的副作用：
summary::marker { display: none; }后，务必补一个自定义图标（如 SVG），否则视觉反馈丢失，且部分屏幕阅读器会读“无内容” - 不要用
font-size: 0或line-height: 0隐藏三角再覆盖，iOS Safari 会因此忽略整个点击区域 - 测试建议：真机用手指悬停 1 秒，看是否有系统级高亮反馈；没反馈就说明热区失效
最常被忽略的一点：语义完整性。如果把关键操作按钮（如“立即购买”“下载 PDF”）藏在 summary 展开后才出现，搜索引擎和屏幕阅读器大概率不会索引或播报它——summary 是渐进式披露，不是内容保险柜。
