enterkeyhint仅改变软键盘按钮文案，不自动触发提交；需确保input在form内、form有action/method、未阻止默认行为，且值必须为小写合法值（如search），搭配type和inputmode才有效。

enterkeyhint 不是事件绑定，它只改键盘按钮文案

加了 enterkeyhint="search" 却没触发提交？这不是 bug，是你误以为它会自动调用 form.submit()。它只影响软键盘右下角按钮的显示文字和语义，不绑定任何行为——iOS 点“搜索”、Android 点“发送”，默认仍按浏览器规则走：有 form 就 submit，没 form 就收起键盘或换行。

常见断点：

• input 不在 form 标签内，或用了 form="xxx" 但对应 form ID 不存在
• form 缺少 action 或 method，Chrome 可能判定“无目标”，点击后仅收起键盘
• 监听了 keydown 并调了 event.preventDefault()，却没手动触发搜索逻辑

哪些值真能生效，哪些只是摆设

合法值只有七个严格小写的字符串：enter、done、go、next、previous、search、send。传错大小写（如 "Search"）或中文（如 "发送"）会被静默降级为 enter。

实际表现差异极大：

• search 是目前兼容性最强的值，iOS/Android 主流键盘基本都显示“搜索”图标，且 type="search" + enterkeyhint="search" 组合最稳
• done 在表单末尾字段（如密码框）上 iOS 更倾向显示“完成”，但部分 Android 厂商键盘（小米、OPPO）可能无视
• send 在 Android Chrome、Samsung Internet 和企业微信 WebView 中较常见，iOS Safari 几乎不认，15.4 之前完全不支持
• next 和 previous 只改文案，不自动跳焦点；真要切换，得靠 tabindex 或 JS 调用 .focus()

必须搭配 type 和 inputmode 才能提高成功率

单独写 enterkeyhint 基本等于白写。浏览器优先看 type 推断语义，enterkeyhint 只是“建议”。比如 type="text" + enterkeyhint="search"，iOS 很可能 fallback 到“前往”或“搜索”，而 type="search" + 同样值，就大概率稳出“搜索”。

HTML Extract

使用 MinerU 从 HTML 页面和文件中提取内容，将 HTML 转换为保持标题、列表、表格及文本层次结构的干净、结构化 Markdown。F...

下载

推荐组合：

• 搜索框：<input type="search" inputmode="search" enterkeyhint="search">
• URL 输入：<input type="url" inputmode="url" enterkeyhint="go">
• 手机号：<input type="tel" inputmode="tel" enterkeyhint="next">
• 聊天输入：<input type="text" enterkeyhint="send" autocomplete="off">（注意：iOS 仍可能不显示“发送”）

真机调试前，别信 DevTools 模拟器

enterkeyhint 对物理键盘和桌面浏览器完全无效，Chrome DevTools 的 Device Mode 也不模拟软键盘行为——它只渲染 DOM 属性，不触发真实键盘 UI。你在模拟器里看到属性存在，不代表手机上真能显示“搜索”。

验证是否生效的唯一方式：

• 用真机访问页面
• 手动点击输入框，确保获得焦点、软键盘弹出
• 观察右下角按钮文字，不是看控制台有没有报错
• 特别注意微信内置浏览器（X5 内核），至今常降级处理，甚至忽略该属性

最容易被忽略的是 Safari 版本：iOS 15.4 之前基本不支持，而很多用户还在用旧系统；更隐蔽的是，某些 Android 厂商定制键盘（尤其带 autocomplete="off" 时）会强制显示“下一步”但点击无效。

前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！