index.html如何制作一个简洁的FAQ常见问题页面
原生 details+summary 是最轻量、语义正确且无障碍友好的无 JS 折叠方案，需确保 summary 为 details 的第一个且唯一子元素，避免嵌套块级标签，并通过 details:target { open: true; } 实现锚点展开。
用 details 和 summary 实现无 JS 折叠效果
现代浏览器（Chrome 12+、Firefox 8+、Safari 6.1+）原生支持 details + summary，不需要写一行 JavaScript 就能做出可展开/收起的 FAQ 条目。这是最轻量、语义正确、无障碍友好的方案。
常见错误是把 summary 当成普通标题乱加样式，结果点击区域变小或失去默认箭头；或是嵌套其他块级元素（如 h3），导致部分浏览器无法触发展开。
-
summary必须是details的**第一个子元素**，且只能有一个 - 避免在
summary内包裹div、h3等块级标签；如需强调，用strong或span即可 - 默认箭头可通过
summary::marker控制，但 Safari 对该伪元素支持有限，建议用背景图或字体图标做兼容
<details> <summary>为什么登录后页面没刷新？</summary> <p>我们使用了客户端路由，登录成功后会自动跳转到首页，无需手动刷新。</p></details>
如何让 FAQ 页面可搜索且支持锚点跳转
用户从外部链接点进 FAQ 页面（比如从帮助邮件里点击“忘记密码怎么办”），需要直接定位到对应条目并展开它。这靠 URL 中的 fragment（#forgot-password）配合少量 CSS 和 HTML 属性就能实现，不依赖 JS。
关键点在于：fragment 匹配的是页面中 id 值，不是 details 的任意属性；而且只有被 hash 指向的 details 需要默认展开，其余保持收起状态。
立即学习“前端免费学习笔记（深入）”；
- 给每个
details添加唯一id，例如id="forgot-password" - 对应链接写成
<a href="#forgot-password">忘记密码？</a> - 用 CSS 强制匹配 fragment 的
details展开：details:target { open: true; }（注意：:target选择器在 Safari 15.4+ 才完全支持open设置） - 为兼容旧版 Safari，可加一行内联
open属性（仅对当前 fragment 生效）：服务端或构建时根据 URL hash 注入，或前端用极简脚本补漏（非必需）
移动端点击区域太小、误触收起怎么办
原生 summary 的点击热区默认只覆盖文字内容，在手机上容易点不准，甚至划动时误触发收起。这不是 bug，是设计使然——浏览器把整个 summary 元素当作可点击区域，但默认 padding 和 line-height 太小。
- 给
summary加padding: 12px 16px，并设cursor: pointer明确提示可交互 - 禁止用户选中文字干扰操作：
user-select: none（不影响屏幕阅读器） - 避免设置
display: block或width: 100%，否则可能撑满父容器、导致右侧空白处也能触发收起 - 如果用了自定义图标（如 ▼/▶），确保图标和文字垂直居中对齐，不要靠
margin-top硬调，改用line-height或flex容器
要不要加搜索框？加的话怎么不引入 JS 框架
纯静态 index.html 里加全文搜索，硬上 algolia 或 lunr.js 就违背“简洁”初衷。真需要搜索，优先用浏览器原生功能：Ctrl+F（Win）或 Cmd+F（Mac）已足够覆盖 90% 场景。
如果产品方坚持要显式搜索框，可以用一个 trick：把 FAQ 内容提前塞进 textarea（display: none），再用极简表单提交跳转到 javascript:void(0) 并调用 window.find() ——但这个 API 已被 Chrome 和 Firefox 标记为废弃，且不返回匹配位置。
- 更实际的做法：放弃客户端搜索，把 FAQ 托管到支持站内搜索的静态托管平台（如 Vercel、Cloudflare Pages 自带 Algolia 集成）
- 若必须本地实现，接受限制：只搜标题（
summary文本），用Array.from(document.querySelectorAll('summary')).filter(...)，代码不到 10 行，但得加<script>标签——这就已经不是“纯 HTML”了 - 多数真实项目里，FAQ 条目少于 20 条时，加搜索框反而增加认知负担，不如优化分类和锚点链接
