<details>标签本身不影响性能，但内部资源会提前加载、内联脚本仍执行、summary嵌套过深、open属性滥用等细节会损害性能，需针对性优化。

<details> 标签本身不阻塞解析、不触发网络请求、不加载子资源，它的原生展开/收起行为完全由浏览器控制，对页面加载性能几乎零影响。

它只是一个语义化容器，浏览器在 HTML 解析阶段仅创建 DOM 节点，内部内容（包括图片、脚本、iframe）默认不参与初始渲染流程，直到用户点击 <summary> 展开后才真正进入渲染管线。

但实际使用中，几个关键细节会悄悄影响性能表现：

• 内部资源仍会加载（除非主动干预）
  <details> 展开前，其子元素中的 <img src="...">、<script src="...">、<iframe src="..."> 等仍会被浏览器发现并发起请求——这是很多人忽略的“假懒加载”陷阱。
  ✅ 正确做法：对非首屏 <details> 中的图片，用 loading="lazy" + 显式 width/height；对脚本，改用 data-src + 展开后动态 setAttribute('src', ...)；iframe 同理。

• 不要在 <details> 内放同步脚本
  即使 <details> 默认收起，里面写 <script>console.log(1)</script> 仍会立即执行（内联脚本无 defer/async 机制）。这可能触发意外逻辑、阻塞解析或报错。
  ✅ 推荐：移出 <details>，或改为事件驱动加载（如监听 toggle 事件后 import() 模块）。

• 避免在 <summary> 里嵌套复杂结构或大量 DOM
  <summary> 是可点击区域，若包含图标、文字、badge 等多层嵌套，可能增加首次绘制时的样式计算与布局开销（尤其在列表页大量使用时）。
  ✅ 建议：保持 <summary> 内容轻量；用 ::marker 控制三角图标；必要时用 font 或 SVG 内联图标替代图片。

• open 属性有渲染代价，慎用于首屏关键区块
  <details open> 会让浏览器在首次渲染时就解析并绘制全部内容，等同于普通 DOM。若内部含大图、视频或第三方组件，会直接拖慢 LCP 和 CLS。
  ✅ 判断标准：首屏内需默认展开的内容，优先评估是否真需 <details>；否则建议用 JS 控制显隐，配合 display: none 或 hidden 属性延迟渲染。

本质上，<details> 是个“语义开关”，不是“资源闸门”。它的性能友好性取决于你怎么装内容，而不是标签本身。