details 和 mark 可共存但需手动联动：必须先按需展开匹配的 details，再在其内容区域动态插入 mark 并清除旧标记，且需转义正则、兼容 safari 渲染延迟。
details 和 mark 能共存，但不能靠简单嵌套自动联动——搜索高亮必须手动触发、作用于展开后的真实文本节点，否则折叠状态下内容不可见，mark 会被浏览器忽略或丢失。
为什么直接在 details 里写 mark 不起作用
常见错误是这样写：
<details><summary>点击展开</summary><p>这是<mark>关键词</mark>内容</p> </details>
问题在于：mark 标签本身不会触发搜索逻辑，它只是静态标记；如果“关键词”来自用户输入，这段 mark 是硬编码的，不随搜索变化；更关键的是，若页面加载时 details 默认收起，部分浏览器（尤其是 Safari）会延迟解析其内部文本节点，导致后续用 TreeWalker 遍历时找不到目标文本。
-
details收起时，内部 DOM 仍存在，但某些浏览器对隐藏文本节点的遍历支持不稳定 -
mark必须由 JS 动态插入，不能靠预渲染——否则无法响应实时搜索 - 如果搜索发生在
details关闭状态，高亮可能被插入到未渲染区域，用户展开后看不到
搜索前先确保 details 已展开
不是强制所有 details 都打开，而是对匹配到的条目做「按需展开」：找到含关键词的 details，再调用 .open = true。
- 用
document.querySelectorAll('details')批量扫描，对每个details的textContent做模糊匹配（注意排除summary文本，避免误触发） - 匹配成功后执行
details.open = true，再在其content区域内执行高亮逻辑 - 别用
scrollIntoView()直接滚到details，应滚到第一个匹配的mark元素，否则可能停在 summary 行上
高亮必须在 details 展开后操作文本节点
核心是把高亮逻辑封装成函数，并在 details.toggle 事件后或搜索触发时调用，且限定作用域为该 details 的 content 部分（即 summary 之后的所有子节点）。
- 用
details.querySelector('summary').nextElementSibling定位内容起始点，避免误高亮 summary 自身 - 创建
TreeWalker时传入该节点作为 root，而非整个document.body - 每次高亮前调用
root.querySelectorAll('mark').forEach(el => el.remove())清除旧标记，防止重复包裹 - 正则关键词必须转义：
keyword.replace(/[.*+?^${}()|[]]/g, '\$&')，否则搜margin: 0 auto会因冒号和空格报错
移动端 Safari 的细节兼容处理
iOS Safari 对 details 内部动态插入 mark 的重绘有时延迟，尤其内容含图片或字体加载中。这不是 bug，而是渲染队列调度策略。
- 不要在
toggle事件回调里立即高亮，加requestAnimationFrame(() => { /* 高亮 */ })确保 DOM 已稳定 - 如果高亮后文字错位，检查是否对
summary或details设置了display: block或浮动——这会破坏原生箭头和热区，间接影响后续节点布局 - 避免在
details内使用innerHTML += ...拼接，改用insertAdjacentHTML('beforeend', ...)，减少重排风险
真正难的不是让 mark 出现在 details 里，而是让每一次搜索都准确识别“该展开哪个、在哪高亮、高亮完是否还可见”。这些判断全依赖对 DOM 结构的即时理解，而不是标签写法本身。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
