在聊天输入框里打出拼音，按 Enter 确认候选词，结果消息提前发了出去。排查时如果只看到 event.key === "Enter"，很容易把这次按键解释为发送命令。
以米米商聊为背景，已整理的手机端资料包含文字聊天。本文借这个场景讨论独立的浏览器 textarea 示例，不代表产品采用 Enter 发送，也不推断手机原生输入框或桌面客户端的实现。发送快捷键在这里是教学示例的明确约定。
1. 同一个 Enter，可能处在两种不同的操作里
用户正在选词时，Enter 可能参与输入法确认；用户已经完成输入时，它才可能符合应用约定的发送快捷键。仅检查键名，缺少了这次按键所处的上下文。
UI Events 规范描述了组合输入期间的键盘事件与 isComposing 状态。实际接入时还要关注组合开始、结束附近的事件顺序。MDN 的 IME 说明特别提醒：边界处可能出现 isComposing 为 false、但事件仍与输入法有关的情况，并给出 keyCode === 229 的兼容检查。
这里的 229 是一个兼容补充。keyCode 已被弃用，不应重新用它维护整套按键映射，也不能据此承诺所有操作系统、输入法与浏览器组合都已兼容。
| 观察到的信息 | 在本文示例中的用途 | 不能据此认定 |
|---|---|---|
key === "Enter" |
判断是否为候选快捷键 | 用户一定想发送 |
isComposing |
识别事件报告的组合状态 | false 就必然与输入法无关 |
| 组件记录的组合状态 | 跟随 start/end 事件维护上下文 | 能修正所有平台事件差异 |
keyCode === 229 |
补充屏蔽常见 IME 边界事件 | 可以替代真实输入法验收 |
2. 先写清楚规则，再写发送监听
下面的输入框约定：不带修饰键的 Enter 请求发送；Shift+Enter 保留为换行；Ctrl、Meta、Alt 组合键交还给其他约定；输入法组合期间不接管 Enter；长按产生的重复 Enter 被消费，但不重复请求发送。
“交还”和“消费”要分开。Shift+Enter 需要保留默认换行，因此不调用 preventDefault()。已经被认作发送快捷键的重复 Enter，则应阻止它插入额外换行。阻止默认行为只说明当前事件的浏览器默认动作被取消，不说明消息已成功送达。
function decideEnter(event, composing) {
if (event.defaultPrevented) return "ignore";
if (composing || event.isComposing || event.keyCode === 229) {
return "ignore";
}
if (event.key !== "Enter") return "ignore";
if (event.shiftKey || event.ctrlKey || event.metaKey || event.altKey) {
return "ignore";
}
return event.repeat ? "consume" : "send";
}
这段函数只作决策，不读取输入框，也不发送网络请求。ignore 表示本监听器不接管；consume 表示取消默认行为但不发送；send 只表示允许进入后续内容检查。
没有设置“结束组合后 100 毫秒内一律不能发”的固定窗口。这样的时间阈值会混合设备速度、输入习惯和事件顺序，还可能吞掉用户随后有意按下的 Enter。若目标环境存在额外差异，应先记录真实事件序列，再设计有依据的兼容策略。
3. 组合结束只更新状态，不触发发送
compositionend 是组合会话结束或取消的事件，而不是业务发送意图，参见 MDN compositionend。不能在这个回调里顺手调用发送：用户可能只是确认了一个词，还要继续输入下一句。
下面把决策函数接到一个原生 textarea。onSend 是外部注入的“请求发送”回调，不代表服务端确认；示例不清空输入框，也不实现请求排队、失败重试或消息回执。
function bindEnterSend(textarea, onSend) {
let composing = false;
const onStart = () => {
composing = true; };
const onEnd = () => {
composing = false; };
const onKeyDown = (event) => {
const action = decideEnter(event, composing);
if (action === "ignore") return;
event.preventDefault();
if (action === "consume") return;
const text = textarea.value;
if (text.trim() === "") return;
onSend(text);
};
textarea.addEventListener("compositionstart", onStart);
textarea.addEventListener("compositionend", onEnd);
textarea.addEventListener("keydown", onKeyDown);
return () => {
textarea.removeEventListener("compositionstart", onStart);
textarea.removeEventListener("compositionend", onEnd);
textarea.removeEventListener("keydown", onKeyDown);
};
}
trim() 只用于拦截全空白内容。真正传给回调的仍是原始字符串，首尾空格和内部换行都保留；是否需要规范化，应由独立的内容规则决定。
同一元素只绑定一次，组件销毁或更换输入框时调用返回的清理函数；重新绑定创建新的组合状态。如果输入框会在组合过程中失焦、隐藏或被框架替换，还应针对这些生命周期路径做真实环境验收，不能假定所有环境都会按预期补齐结束事件。
4. 键盘路径正确，也要防止其他路径重复提交
这份示例只管理输入框自身的键盘监听。接入应用时，还需要梳理发送按钮、表单提交和外层快捷键的关系：谁负责识别意图，谁负责创建请求，谁负责呈现服务端状态。
例如，同一次操作如果既经过 keydown 的回调，又经过表单的提交逻辑，就可能形成两条发送路径。preventDefault() 不等于停止事件传播；监听器仍可能收到冒泡事件。外层逻辑应遵守已经处理的事件标记，并限定自己的适用范围。不要为了省事在整个页面拦截所有 Enter。
发送按钮也应保留，便于触屏、辅助技术或不使用该快捷键的用户操作。按钮与快捷键最终进入同一个业务入口；异步发送期间的重复请求控制、幂等处理和失败后草稿保留，需要在那个入口实现。本文的 repeat 检查只处理键盘长按，无法拦截两次独立按键、连续点击或网络重试。
5. 用事件序列验证，而不是只测一个布尔值
独立验证从本文两段 JavaScript 原样提取函数，使用合成事件对象及最小事件目标替身，检查决策、回调次数、默认行为取消和监听器清理。重点不是模拟出一个看似真实的输入法，而是让每条规则有明确预期。
| 输入或事件顺序 | 预期 |
|---|---|
| 普通 Enter，正文非空 | 取消默认行为，请求发送一次 |
| Shift+Enter 或其他修饰键组合 | 本监听器不接管 |
| start → Enter，事件标记为 false | 组件状态仍拦截发送 |
end → Enter，keyCode 为 229 |
兼容分支拦截发送 |
| 只有 end，没有新的发送按键 | 不请求发送 |
| 普通 Enter，内容只有空白 | 取消默认行为，不发送 |
| 重复 Enter | 取消默认行为，不新增发送 |
| 销毁后再派发事件 | 旧监听器不再执行 |
此外，逐一覆盖四种修饰键的所有组合，防止只测 Shift 而遗漏其他键。测试还检查正文空格与换行没有被裁剪，以及两个输入框的组合状态互不影响。
这些检查验证的是教学代码的分支和绑定逻辑，没有操作真实输入法候选窗，也没有进行真实消息发送。合成事件通过，不能写成“已覆盖 Windows、macOS、手机软键盘”。实际发布前，应记录目标系统、浏览器版本、输入法及具体操作，再验收选词确认、取消组合、失焦返回、连续输入和换行等路径。
6. 把“输入完成”和“请求发送”分开
一个可解释的输入框，需要保留三个边界：组合输入负责形成文字；快捷键策略负责识别发送意图；业务发送入口负责请求状态和结果。候选词确认不应自动跨越到业务发送，组合结束也不等于用户已经写完消息。
排查误发送时，可以先记录事件类型、键名、组合标记、重复标记以及是否取消默认行为，复原具体顺序；日志无需记录聊天正文。修正后，再对同一条真实输入序列做回归，避免只修好英文键盘路径。
本文为独立教学示例，部分内容由 AI 辅助整理，代码与发布内容经独立核对。
