关键在于参数名、method与后端预期严格匹配：name须完全一致（大小写敏感），GET检索用完整URL的action和method="get"，POST则必须显式声明并注意CSRF等额外要求。

直接用 form 标签对接全文检索服务器，关键不是“能不能做”，而是“参数对不对、提交方式是否匹配后端预期”。多数失败案例都卡在 name 属性写错、method 用反、或漏掉隐藏参数上。

确认搜索接口的接收参数名和传参方式

打开目标搜索页面（比如 https://example.com/search），手动搜一个词，观察地址栏变化。常见模式有：

• 百度类：URL 变成 https://www.baidu.com/s?wd=关键词 → 参数名是 wd，用 GET
• 某些 CMS 或自建系统：URL 是 https://site.com/search?q=关键词&scope=all → 需要同时传 q 和 scope
• 带固定过滤条件的：如 https://api.example.com/v1/search?source=web&lang=zh → 必须补 <input type="hidden" name="source" value="web">

别猜，直接看浏览器开发者工具的 Network → Headers → Query String Parameters 栏，里面列出的就是真实需要的参数名和值。

用 form 正确构造 GET 检索请求

GET 是全文检索最常用的方式，因为结果可分享、可缓存、调试直观。但必须注意三点：

anything-to-html

将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。

下载

• action 必须是完整 URL（含协议），不能只写路径，否则可能相对当前页拼接出错
• method="get" 可省略（默认就是 GET），但显式写出更清晰
• input 的 name 必须和接口要求完全一致，大小写敏感；比如要 q，写成 Q 或 query 就收不到
• 移动端用户常按回车触发搜索，确保 input 在 form 内，且没被 JS 阻止默认行为

示例（对接百度）：

<form action="https://www.baidu.com/s" method="get" target="_blank">
  <input type="search" name="wd" placeholder="站内搜索..." autocomplete="off">
  <button type="submit">?</button>
</form>

POST 方式对接的特殊注意事项

少数全文检索接口强制用 POST（比如带鉴权、需防篡改、或参数超长）。这时容易踩坑：

• form 必须明确写 method="post"，否则仍是 GET
• 后端通常要求 Content-Type: application/x-www-form-urlencoded（form 默认满足），但若后端期望 JSON，就不能直接用 form，得换 fetch
• CSRF token 如果存在，必须作为 <input type="hidden"> 塞进表单，且值需服务端动态生成（静态 HTML 无法解决）
• 不要给 submit 按钮设 name="submit" —— 这会多传一个 submit=搜索，可能干扰后端解析

为什么加 target="_blank" 很实用

用户搜索后跳转到结果页，不希望离开原网页？加 target="_blank" 最简单可靠。但要注意：

• 部分浏览器会拦截弹窗，如果页面未与用户发生交互（比如刚加载完就自动 submit），可能失败
• 若想控制新窗口尺寸或特性（如无工具栏），不能靠 form 实现，得用 window.open + fetch 组合
• SEO 友好性：搜索引擎能正常抓取 form 的 action 地址，但不会执行 JS 弹窗逻辑

真正难处理的不是表单结构，而是后端接口文档模糊、参数命名不一致、或悄悄加了签名验证 —— 这些问题 form 标签本身无能为力，得先和后端对齐契约。