关键在于参数名、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 是全文检索最常用的方式，因为结果可分享、可缓存、调试直观。但必须注意三点：
-
action必须是完整 URL（含协议），不能只写路径，否则可能相对当前页拼接出错 -
method="get"可省略（默认就是 GET），但显式写出更清晰 -
input的name必须和接口要求完全一致，大小写敏感；比如要q，写成Q或query就收不到 - 移动端用户常按回车触发搜索，确保
input在form内，且没被 JS 阻止默认行为
示例（对接百度）：
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 标签本身无能为力，得先和后端对齐契约。
