textarea 的 enterkeyhint="send" 仍换行，因其仅改软键盘按钮文案而不改变默认行为；iOS 多数键盘显示“换行”或“搜索”，Android 部分机型忽略该属性；需配合 keydown 监听、isComposing 判断及 Shift+Enter 换行约定实现兼容提交。
textarea 里设 enterkeyhint="send" 为什么还是换行
因为 textarea 的默认行为就是按 Enter 换行，enterkeyhint 不会覆盖这个行为，只改软键盘右下角按钮文案。iOS 上多数键盘仍显示「换行」或「搜索」，Android 部分键盘（如小米、OPPO）甚至直接忽略该属性。
常见失效场景：
-
enterkeyhint="send"用在textarea上，但用户点了“发送”后没触发提交——这不是属性写错了，是没监听keydown或没阻止默认换行 -
type="textarea"写法错误：HTML 中没有type="textarea"，正确标签是<textarea>，写成<input type="textarea">属于无效 DOM，属性自然不生效 - 微信 X5 内核或低版本 Android WebView 完全不支持该属性，连文案都不改，静默 fallback 到
enter
想让多行输入框既支持换行又支持回车提交，怎么配
核心原则：不能只靠 enterkeyhint，必须配合 JS 控制行为。软键盘的「发送」按钮只是视觉提示，逻辑得自己写。
推荐做法：
立即学习“前端免费学习笔记（深入）”；
- 用
<input type="text">替代<textarea>，配合 CSS 实现视觉上的多行效果（如white-space: pre-wrap; overflow-y: auto; height: 80px;），这样enterkeyhint="send"在 Android 上更易生效 - 监听
keydown事件，区分是否为真实 Enter 键（优先用event.code === 'Enter'，比event.key更可靠） - 检测是否处于中文输入法组合状态：
if (event.isComposing) return，避免用户还没输完就触发提交 - 需要换行时：按住 Shift + Enter；正常回车即提交——这是目前最兼容的交互约定
为什么 inputmode="text" + enterkeyhint="send" 比 textarea 更稳
inputmode 是向系统声明输入意图的更强信号，而 textarea 天然被系统判定为「多行编辑器」，其软键盘行为优先级高于 enterkeyhint。Chrome 和 Safari 对 inputmode 的响应比对 enterkeyhint 更积极。
实操差异：
-
<input type="text" inputmode="text" enterkeyhint="send">：Android Chrome、Samsung Internet、企业微信 WebView 基本显示「发送」，iOS Safari 16.4+ 也识别，且不会自动换行 -
<textarea inputmode="text" enterkeyhint="send">：iOS 几乎无视，Android 多数键盘仍显示「换行」，inputmode在textarea上支持度极低 -
inputmode="verbatim"或"latin"可进一步抑制输入法干扰，适合聊天类场景
真机调试前最容易漏掉的三件事
enterkeyhint 是个典型「写了不等于有效」的属性，桌面模拟器完全不渲染软键盘 UI，所有判断都得靠真机验证。
上线前必须确认：
- 目标设备系统版本：iOS
- 是否在
<form>内：不在表单里的input即使设了enterkeyhint="search"，iOS 也可能 fallback 成「前往」 - 有没有监听
keydown并调event.preventDefault()：没这句，哪怕键盘显示「发送」，点击后仍会触发默认换行或提交
最麻烦的不是写错，而是以为它生效了——结果用户点「发送」没反应，才发现 JS 逻辑压根没接住。
