要实现搜索过滤需用JS动态控制details显隐，通过data-keywords属性匹配并合理设置hidden或visibility+height隐藏，缓存恢复open状态，防抖处理输入事件，并规范化文本比对。
details 标签本身不支持搜索过滤，得靠 JS 动态控制显隐
原生 <details> 只响应点击 <summary> 的展开/收起，没有内置搜索逻辑。要实现“输入关键词后只显示匹配的折叠项”，必须用 JS 遍历所有 <details>，根据其内容或 data-keywords 属性做匹配，并手动设置 open 属性或切换 CSS 类。
关键点在于：不能只靠 display: none 隐藏——那样会破坏 <details> 的语义和可访问性；推荐用 hidden 属性或 visibility: hidden + height: 0 组合，保留 DOM 结构和焦点流。
- 搜索前先保存每个
<details>原始的open状态（避免搜索后全部关闭） - 匹配逻辑建议统一用小写比对：
textContent.toLowerCase().includes(keyword.toLowerCase()) - 避免在
input事件里高频重绘，加个setTimeout防抖（300ms 足够）
给 details 添加 data-keywords 提升搜索准确度
直接搜 <summary> 文本容易漏掉隐藏内容，比如折叠区里有“React Router v6 的 useNavigate 替代了 useHistory”，但 summary 只写了“路由跳转”。这时候在 <details> 上加 data-keywords="react router usenavigate usehistory"，JS 就能命中更准。
示例结构：
使用 Puppeteer + Chrome 将 HTML 渲染为中文 PDF，自动处理图表等待、Tab 展开、动画、测高、白边消除、防分页，适用于看板、报表、网页和交互图表转 PDF。
立即学习“前端免费学习笔记（深入）”；
<details data-keywords="fetch api cors json"> <summary>如何处理跨域请求？</summary> <p>使用 <code>mode: 'cors'</code> 并确保服务端返回 <code>Access-Control-Allow-Origin</code>...</p> </details>
-
data-keywords值用空格分隔，不用逗号——方便.split(/\s+/)处理 - 如果没写
data-keywords，回退到取<summary>和第一个子元素的文本拼接 - 别把敏感信息或长段落塞进
data-keywords，它只用于快速模糊匹配
搜索时保持已展开项的 open 状态不被重置
用户可能边查边看，比如先展开“Promise 错误处理”，再搜“catch”，结果整个列表刷新，刚才展开的项又关了——体验断裂。解决方法是：搜索前缓存所有 open === true 的 <details> 元素引用，匹配完再批量恢复它们的 open 属性。
- 缓存用
Set存 DOM 元素，比存索引更可靠（DOM 可能动态增删） - 恢复
open要在details元素已显示的前提下执行，否则 Safari 会忽略 - 如果某项匹配失败但之前是展开的，可以设为
open = false，也可以留开——取决于产品逻辑；多数场景选“留开”更自然
移动端键盘收起后自动聚焦搜索框的问题
在 iOS Safari 上，点击 <summary> 展开后，软键盘可能意外弹出又收起，导致页面滚动错位。根源是某些机型把 <summary> 当作可聚焦元素，而搜索框又用了 autofocus 或 JS .focus()。
- 移除搜索
<input>的autofocus属性 - JS 中避免在
DOMContentLoaded里调.focus()，改用setTimeout(() => input.focus(), 0)延迟执行 - 监听
touchstart在<summary>上阻止默认行为（仅当非搜索框点击时），防止误触发 - 真机测试时重点看展开后是否出现“页面上跳+键盘闪退”现象，这是典型焦点冲突信号
textContent 包含代码块、<pre> 里的换行和缩进，会导致比对字符串过长且含大量空白。应该先 .replace(/\s+/g, ' ').trim() 再匹配，不然“useEffect”和“ useEffect ”就成两个词了。 
