标签本身不支持content-visibility: auto优化，因其展开逻辑依赖用户交互而非视口可见性；应将该属性用于其内部静态子列表容器，并配合contain-intrinsic-size确保滚动稳定。
details 标签本身不触发 content-visibility 的优化逻辑
直接给 <details></details> 元素设置 content-visibility: auto 几乎无效——因为 <details></details> 的内容是否渲染，由其 open 属性控制，而非浏览器的视口可见性判断。浏览器不会对一个“逻辑上被折叠但仍在 DOM 中、且可能随时被点击展开”的元素启用延迟渲染，否则会破坏交互响应性。
常见错误现象是：加了 content-visibility: auto 后，<details></details> 在收起状态下仍占用大量内存或布局开销，性能无改善；甚至在某些 Chrome 版本中，auto 会与 <details></details> 的内部状态冲突，导致 open 切换卡顿或样式错乱。
-
content-visibility: auto依赖浏览器对“不可见区域”的保守预判，而<details></details>是用户主动触发的交互容器，不属于“可安全跳过渲染”的长列表场景 - 它适合包裹静态、可预测高度的子项（如
<div class="item">），不适合包裹语义化交互组件<li>若强行套用，需配合 <code>contain-intrinsic-size防止折叠/展开时重排，但代价是失去<details></details>原生的高度自适应能力
真正能结合的场景：details 内部的长列表子项
当 <details></details> 展开后，其内容区包含大量子项（比如 500 条日志、100 个配置项），这时可在子容器上启用 content-visibility，而不是作用于 <details></details> 自身。
例如：
<details><summary>系统日志</summary><div class="log-list" style="content-visibility: auto; contain-intrinsic-size: 48px;">
<div class="log-item">[2026-08-19] 启动成功</div>
<div class="log-item">[2026-08-19] 加载配置完成</div>
<!-- ... 498 more -->
</div>
</details>
-
log-list容器必须有明确的单行高度估算（contain-intrinsic-size），否则滚动条会抖动 -
<details></details>保持原生行为，仅负责开关逻辑；content-visibility负责子项的渲染调度 - 注意：如果子项高度差异大（如含图片、多行文本），
contain-intrinsic-size设为平均值会导致部分项被裁剪，需配合contain: layout style paint或改用虚拟滚动
与 visibility: hidden 的关键区别不能混淆
有人试图用 visibility: hidden 替代 <details></details> 的收起状态，再叠加 content-visibility: auto，这是危险组合。
visibility: hidden 只隐藏视觉，不阻止布局和绘制；而 content-visibility: auto 在不可见时跳过布局与绘制——两者机制冲突，浏览器可能忽略后者，或在 visibility: visible 切换瞬间触发整块重绘，反而更慢。
-
<details></details>收起时，DOM 仍在，但内容不参与渲染流程（类似display: none的效果，但保留占位） -
visibility: hidden下，元素仍参与 layout 和 paint，只是最终像素不输出，content-visibility: auto对它无效 - 真要隐藏又保空间，用
content-visibility: hidden——但它不适用于<details></details>，因该属性会彻底冻结子树，导致open点击无响应
移动端兼容性与 fallback 必须手动处理
截至 2026 年 8 月，content-visibility 在 Safari（iOS / macOS）中仍需 -webkit- 前缀，且部分旧版 Android WebView 完全不支持；而 <details></details> 在 IE 和老版 UC 浏览器中需要 polyfill。
这意味着：如果你在 <details></details> 内部用 content-visibility，必须分层降级：
- 先检测
content-visibility支持：@supports (content-visibility: auto)，只在支持环境下启用 - 对不支持环境，用 JS 控制子项的
display: none+ 滚动监听模拟“按需加载”，或直接放弃优化 - 不要指望
<details></details>的 polyfill（如 details-element）能兼容content-visibility，它们互不感知
最易被忽略的一点：当 <details></details> 处于收起状态时，即使子容器启用了 content-visibility: auto，它的占位高度仍由 contain-intrinsic-size 决定——这个值一旦写死，就无法随内容动态变化，所以它只适合结构规整、高度可控的列表，不适合混排图文或富文本区块。
