必须用name="q"的input，结果区用包裹、每条用、标题用、摘要用；关键词高亮需转义正则并加单词边界；空状态需含原因和操作指引。
input 必须带 name="q"，否则后端或 JS 拿不到关键词；<main></main> 包裹结果区、每条用 <article></article>、标题用 <h3></h3>、摘要用 <p></p>——结构不对，SEO 和屏幕阅读器就直接失效。
搜索框怎么写才不丢参数
用户输完点回车或按钮，却收不到关键词？大概率是 input 少了 name 属性。浏览器只提交带 name 的字段，value 再对也没用。
-
<input type="search" name="q" placeholder="输入关键词">是最简可靠写法；name值推荐用q，和主流搜索引擎 URL 一致（如?q=html） - 别用
id代替name——id只用于 DOM 定位，不参与表单提交 - 如果走 JS fetch，也要手动从这个
input取.value，不能靠表单自动收集 - 移动端注意：iOS 上
type="search"的 placeholder 默认左对齐，若需居中，得用伪元素或 JS 模拟，不能只靠text-align: center
搜索结果 HTML 结构为什么不能用 div 堆
把所有结果塞进一个 <div class="results">，看似省事，实则埋下三类问题：爬虫抓不到标题层级、键盘导航跳转混乱、后续加高亮或埋点无锚点。
<ul>
<li>必须用语义容器：<code><main></main> 包整体结果区，每条结果用 <article></article>（可选但推荐加 role="article"）
<h3></h3>（不是 <h2></h2> 或 <div>），确保层级连续；已有页面 <code><h1></h1> 的前提下，<h3></h3> 是合理次级
<p></p>，不能用 <span></span> 或 <div>——前者无段落语义，后者易被读屏软件跳过
<li>初始 HTML 至少保留 1 条真实结果（哪怕只是示意），否则 Lighthouse 会扣“首屏无内容”分，纯 JS 渲染也得预留骨架结构</li>
<h3>关键词高亮的正则和 XSS 防御怎么做</h3>
<p>直接 <code>string.replace(/keyword/gi, '<mark>$</mark>') 是危险操作：特殊字符会破坏 HTML，用户搜 js<script>alert(1)</script> 就可能触发 XSS。
- 先对关键词做正则转义：
keyword.replace(/[.*+?^${}()|[]\]/g, '\$&')（注意&是 HTML 实体） - 匹配要加单词边界：
new RegExp(`\b(${escapedKeyword})\b`, 'gi')，避免把javascript里的js错高亮 - 插入 DOM 前必须剥离 HTML 标签：用
textContent提取纯文本，再用innerHTML拼接<mark></mark>，不能直接对含标签的字符串操作 - 更安全的做法：用
document.createTextNode()创建文本节点，再用insertAdjacentHTML插入高亮部分，完全避开 innerHTML 解析风险
空结果状态不是留白，而是要可操作
用户搜完一片空白，第一反应不是“没数据”，而是“是不是我输错了”或“页面坏了”。HTML 层只需提供明确结构，样式由 CSS 控制，但语义不能省。
- 空状态容器仍用
<main></main>，里面放<p class="no-results"></p>，不要用<div> <li>文案必须包含两层信息：“为什么没结果”（如“未找到与‘xyz’匹配的内容”） + “还能做什么”（如“换个关键词试试，或看看热门搜索”）</li> <li>“热门搜索”链接需是真实 <code><a href="?q=xxx"></a>，不能只是 JS 绑定 click——保证无 JS 时仍可访问 - 别在空状态里塞 SVG 或图标字体：若加载失败，用户看到的是空白方块，文字提示才是底线保障
真正难的不是写出能跑的结构，而是让每个 <article></article> 在无 JS、低网速、读屏模式、SEO 抓取这四种场景下都保持可用——这些地方一旦漏掉，修复成本远高于初始搭建。
