移动端回车键显示“搜索”或“发送”而非“下一步”，是因为未设置或浏览器不支持/忽略enterKeyHint="next"；该属性仅提示软键盘显示对应图标，合法值仅限enter、done、go、next、previous、search、send七个，且需配合可聚焦的下一个元素及合理DOM顺序才能生效。
移动端表单里回车键为啥总是“搜索”或“发送”，不能改成“下一步”？
因为 enterKeyHint 属性没设，或者设了但浏览器不支持/被忽略。这个属性是专门用来告诉输入法（IME）该显示什么回车键图标的，不是 JS 事件钩子，也不影响 keydown 的 key 值——它只改软键盘右下角按钮的语义和图标。
常见错误是以为加个 onKeyDown={e => e.key === 'Enter' && e.preventDefault()} 就能控制软键盘行为，其实完全无关：阻止事件不影响键盘 UI，只影响后续逻辑。
-
enterKeyHint必须写在<input>或<textarea>上，父容器或 form 标签上无效 - 可选值只有有限几个：
"enter"、"done"、"go"、"next"、"previous"、"search"、"send"；没有"submit"或"continue"这类自定义值 - iOS Safari 16.4+ 才开始支持，旧版直接忽略；Android Chrome 稳定支持，但部分国产定制输入法（如百度、搜狗）可能仍强制显示“搜索”
如何让邮箱输入框后显示“下一步”而不是“搜索”？
关键不是监听回车，而是让输入法知道当前字段之后还有下一个焦点。需要同时满足三件事：声明 enterKeyHint="next"、确保下一个可聚焦元素存在、且 DOM 顺序/ tabindex 合理。
示例：
<input type="email" enterKeyHint="next" id="email" /> <input type="password" enterKeyHint="done" id="password" />
- 如果
#password被display: none或disabled，iOS 输入法大概率 fallback 到"search" - 不要依赖 JS 动态插入下一个 input 后再设
enterKeyHint——输入法在 focus 时就读取该属性，动态改无效 -
tabindex不影响enterKeyHint行为，但若下一个元素不可聚焦（比如只是<div>），软键盘仍会显示"done"或默认值
为什么设了 enterKeyHint="send"，微信内置浏览器里还是显示“搜索”？
微信 iOS 客户端用的是系统 WebKit 内核，但禁用了部分新 API 的渲染逻辑，enterKeyHint 就是其中之一。这不是 bug，是明确限制——微信 WebView 的 UA 里带 WV 标识，本质上是个阉割版 Safari。
应对方案只有降级处理：
- 对微信 UA，放弃依赖
enterKeyHint，改用视觉提示（比如输入框右侧加“下一步”文字按钮） - 保留
enterKeyHint给标准浏览器，不报错也不移除，未来兼容性会逐步提升 - 别试图用
document.execCommand或模拟 focus 来绕过——这些在现代 WebView 里基本失效
enterKeyHint 和 inputmode 配合使用时要注意什么？
两者独立生效，但组合不当会导致输入法行为混乱。例如 inputmode="numeric" + enterKeyHint="search"，数字键盘上出现“搜索”按钮，用户直觉是“完成输入”，结果点了却触发了搜索逻辑，体验断裂。
-
inputmode="tel"或"numeric"场景下，优先用"done"或"next"，避免"search"/"send" -
inputmode="url"可配"go"，inputmode="email"推荐"next"，语义才一致 - Android 上部分输入法会根据
inputmode覆盖enterKeyHint（尤其三星键盘），所以必须真机测试，不能只看 Chrome DevTools 模拟
最麻烦的点其实是不可见的：你没法通过 JS 读取当前输入法实际渲染出的按钮文字，也没法监听“用户点击了软键盘回车键”这个动作本身——它和物理 Enter 键共用 keydown.enter 事件，但触发时机、是否冒泡、是否可取消，各平台差异极大。能做的只有声明意图，然后接受现实。
