details元素无法被scrollIntoView()正确锚定，因其折叠态高度被计算；需先设open=true、等待重排，再滚动内部.details-body并配合scroll-padding-top避开sticky头部。
<details> 在单页长滚动网页里不会自动“定位”——它不参与锚点跳转，也不响应 scrollIntoView() 的默认行为。想让它随滚动精准出现在视口内，得靠 CSS 位置控制 + JS 状态同步，而不是指望它自己“跟过去”。
为什么 details 元素无法被 scrollIntoView() 正确锚定
原生 <details> 是一个可折叠容器，其展开后的内容高度是动态的；当目标元素是 <details> 本身时，element.scrollIntoView() 会按其**折叠态高度**（通常只有 <summary> 那一行）计算滚动位置，导致展开后内容被截断或错位。
常见现象：<details open> 滚动到顶部后，展开内容下半部分仍不可见；或者点击导航项后，页面停在 summary 行，但详情区域被 sticky 导航栏盖住。
- 根本原因：浏览器对
<details>的 layout 尺寸判断发生在折叠态，scrollIntoView()不感知后续展开带来的高度变化 - 不能靠
getBoundingClientRect()直接取展开后尺寸——除非先强制触发open并等待重排（需offsetHeight或getComputedStyle触发） - 若用
scrollIntoView({ block: 'start' })，必须确保目标是展开后的实际内容区域（比如内部<div class="details-content">），而非<details>根节点
如何让 details 展开后真正“可见”并避开 sticky 头部
正确做法是：不滚动 <details>，而是滚动其内部第一个块级内容容器，并手动补偿 sticky 导航栏高度。
立即学习“前端免费学习笔记（深入）”；
- 给每个
<details>内部的详情内容加唯一 class，例如<div class="details-body"> - 点击导航项时，先
detailsEl.open = true，再等一帧（requestAnimationFrame或queueMicrotask）确保 DOM 重排完成 - 调用
document.querySelector('.details-body[data-id="faq-2"]').scrollIntoView({ block: 'start', behavior: 'smooth' }) - 配合 CSS 设置偏移：在 body 上加
scroll-padding-top: 80px（值等于 sticky header 高度），比 JS 计算更稳定
IntersectionObserver 监听 details 可见性时的坑
直接监听 <details> 元素的交叠状态会失效——因为折叠态下它的 boundingClientRect.height 极小（甚至为 0），isIntersecting 常为 false，即使内容已展开。
- 必须监听的是展开后的真实内容区域，如
.details-body，且该元素需有明确高度（不能是height: auto且父级未设高） - 设置
threshold: [0, 0.2, 0.5]而非仅[0]，避免因滚动过快漏判 - 如果
.details-body包含异步加载内容（如图片、iframe），需在内容加载完成后再次调用observer.unobserve()+observer.observe()刷新检测
移动端 Safari 中 details 定位失效的典型原因
不是 JS 逻辑问题，而是渲染层未启用硬件加速，导致 scrollIntoView() 后位置抖动、回弹或卡在错误 offset。
- 给
<details>或其父容器添加transform: translateZ(0)或will-change: transform - 确保没有在
body或滚动容器上误设overflow: hidden，这会截断滚动行为 - 避免在
details[open]的 CSS 过渡中使用max-height动画——它会干扰浏览器对真实高度的判断，进而影响scrollIntoView()的目标位置计算
最易被忽略的一点：所有基于 <details> 的滚动定位，都依赖于它是否已处于 open 状态。没展开就调用 scrollIntoView()，等于对一个“看不见的高度”做计算——结果必然不准。必须把“展开”和“滚动”拆成两个明确步骤，且中间留出渲染时机。
