enterkeyhint在chrome android 79+、edge mobile 79+、safari ios 16.4+中支持；ios 16.3及更早版本完全忽略；android webview通常跟随chrome版本，但微信x5等定制内核可能不支持，应视为可选增强而非功能依赖。
移动端 enterkeyhint 哪些浏览器能用
Chrome Android 79+、Edge Mobile 79+、Safari iOS 16.4+ 开始支持 enterkeyhint；iOS 16.3 及更早版本完全忽略该属性，连 fallback 都不触发。Android WebView（基于 Chromium）通常跟随系统 Chrome 版本，但部分厂商定制 WebView（如微信内置 X5）可能直接无视该属性——不是 bug，是没实现。
实操建议：
- 永远把
enterkeyhint当作增强体验的可选提示，而非功能依赖项 - 在 iOS enterkeyhint="search" 仍会显示「回车」或「换行」，无法强制改文案
- 可用
if ('enterKeyHint' in document.createElement('input'))检测原生支持，但注意这仅反映 DOM 接口存在，不保证软键盘实际响应
enterkeyhint 的合法值和对应软键盘按钮行为
只有 enter、done、go、next、previous、search、send 这 7 个值被规范定义。其他值（如 submit、confirm）会被浏览器忽略，降级为默认 enter。
常见误用场景：
-
enterkeyhint="search"用在非搜索框（比如地址输入），iOS 会显示「搜索」但点击后仍触发换行——因为底层未绑定搜索逻辑，只是改了按钮文字 -
enterkeyhint="next"在表单末尾字段使用，部分 Android 厂商键盘仍显示「完成」，不跳转（无焦点链时无效） -
enterkeyhint="send"在<textarea></textarea>上效果不稳定：iOS 16.4+ 显示「发送」，但 Android 多数仍为「换行」
和 type、inputmode 配合才真正生效
enterkeyhint 单独写几乎没用。它必须和语义匹配的 type 和 inputmode 组合，系统才更可能采纳提示。
有效组合示例：
- 搜索框：
<input type="search" inputmode="text" enterkeyhint="search"> - 短信发送：
<input type="text" inputmode="text" enterkeyhint="send">（type="tel"时enterkeyhint="send"多数无效） - 多步表单下一步：
<input type="text" inputmode="text" enterkeyhint="next">，且确保下一个可聚焦元素存在并可达
注意：inputmode="numeric" 时，enterkeyhint 几乎全部失效——数字键盘的确认键由系统硬编码，无法覆盖。
真机测试绕不开的三个坑
模拟器/DevTools 里的软键盘不会响应 enterkeyhint，必须真机验证。常见翻车点：
- iOS Safari 真机上，
enterkeyhint="go"在某些页面上下文中显示为「前往」，但点击后不跳转 URL（需手动监听keydown捕获 Enter 并调用window.location） - Android 键盘设置为「Gboard」时表现正常，但换成三星键盘或华为 EMUI 键盘，
enterkeyhint="search"可能退化为「回车」且无图标变化 - Vue/React 中动态设置
enterkeyhint（如通过:enterkeyhint绑定）可能不触发键盘重绘——需要 focus 后 blur 再 focus 才刷新按钮文案
最稳妥的做法：把 enterkeyhint 当成视觉提示补丁，核心交互逻辑仍靠 keydown + event.key === 'Enter' 拦截和处理。软键盘文案只是锦上添花，别让它决定功能是否可用。
