回车提交的行为需明确
别名: 回车提交 · Enter submits · implicit submission · 表单回车
概念解释
在许多桌面浏览器里，单行输入里按回车会触发表单的隐式提交。人可能以为回车等于「去下一空」，实际把未填完的表送了出去；也可能以为回车会提交，实际什么都不做。行为需明确指：产品要先决定回车在当前上下文是提交、换行还是移到下一项，并把这个决定做成人能预测的——按钮文案、主按钮位置、多行框里回车换行、单行里回车的后果一致。Tab 顺序乱不乱、手机键盘有没有「下一项」，是另两件事。
机制
回车在键盘上是「完成当前」。完成当前在聊天里是发送，在文字处理里是换行，在多字段表单里历史上却常被浏览器映射成提交。人带着最近用过的那个映射进来。第二层是隐式提交的目标按钮不稳定：浏览器会选第一个 type=submit，若 DOM 里先写了「删除」或「发送验证码」，回车就触发了那个次要动作。多行文本域里回车该换行，若父表单仍在听回车提交，长文会在第一段结束时被送走。明确行为不是禁止回车提交，而是让「完成当前」的含义在这一屏只有一个，并且那个动作的按钮就是回车会打到的按钮。
怎么研究
给单字段登录、多字段资料表、含多行备注的表，分别记录回车的后果。比较「回车提交主动作」「回车移到下一项」「回车无效果」。
自变量：字段数、是否含 textarea、DOM 中第一个 submit 是否为主动作、是否拦截回车。
因变量：未完成即提交的次数、回车打到次要按钮的次数、多行里误提交、人事前预测的回车含义是否命中。
实验室里会有人先问「回车会怎样」，预测被污染。要先让他们按，再问以为会怎样。移动端系统键盘的「前往 / 搜索 / 换行」与桌面回车不是同一键，要分开测。
边界
真正的单字段检索或登录，回车提交是平台惯例，改成「只准点按钮」会显得残缺。IME 组词过程中的回车是上屏，不是提交，拦截回车必须放过组成阶段。游戏或终端嵌在表单里时，回车属于内嵌控件。触摸优先、没有实体回车键的设备上，这条主要约束外接键盘。无障碍用户依赖回车激活主按钮的，取消隐式提交后必须保证主按钮仍可被键盘激活。
怎么落地
- 多字段表单：要么让回车只触发视觉上的主按钮（且 DOM 里第一个 submit 就是它），要么拦截回车改为移到下一项，并在主按钮上看得出「按回车也可」。
- 有多行文本时，回车在该字段内只换行；提交改走主按钮或快捷键组合，不要在第一段结束时送出整表。
- 不要把「删除」「获取验证码」做成排在前面的
type=submit。 - 验证：在姓名框按回车，确认不会提交整表、也不会点到「删除」。在备注框按回车，确认只多一行。登录页只有密码框时，回车应提交登录。用输入法组词时按回车，确认不会误提交。