必须监听form的submit事件并首行调用event.preventdefault()，因为回车提交触发的是submit事件而非keydown事件，仅拦截keydown无法阻止后续默认提交行为。
为什么 event.preventDefault() 有时不生效
回车键触发表单提交，本质是浏览器对 <form></form> 内第一个可提交按钮（通常是 <button type="submit"></button> 或 <input type="submit">）的自动行为。仅监听 keydown 并调用 event.preventDefault() 往往无效——因为表单提交由 submit 事件触发，而该事件在 keydown 后才发生，且不依赖按键事件的阻止状态。
常见错误写法：
form.addEventListener('keydown', e => {<br> if (e.key === 'Enter') e.preventDefault(); // ❌ 无法阻止提交<br>});
-
keydown阶段无法取消后续的submit流程 - 即使阻止了
keydown，浏览器仍会按默认逻辑触发submit - 焦点在非输入控件（如
<div contenteditable>）时行为更不可靠 <h3>正确拦截：优先监听 <code>submit事件真正可控、稳定、语义正确的拦截点是
submit事件本身。它在表单准备提交前触发，且preventDefault()能直接中断整个流程。实操建议：
- 给
<form></form>绑定submit事件，而非keydown - 检查
e.submitter判断是否由回车触发（现代浏览器支持）：e.submitter === null表示无显式点击按钮，大概率是回车 - 若需兼容旧浏览器，可用
document.activeElement辅助判断焦点是否在输入类元素上
示例：
form.addEventListener('submit', e => {<br> if (e.submitter === null) {<br> e.preventDefault();<br> console.log('回车提交被拦截');<br> // 手动执行自定义逻辑，如 AJAX 提交<br> }<br>});需要保留
keydown的场景：比如编辑器内回车换行当表单内含
contenteditable或富文本编辑器，用户期望回车换行而非提交，此时必须在keydown阶段干预，但需配合额外控制防止冲突。- 只在目标元素（如
div[contenteditable]）上监听keydown，避免全局干扰 - 检测
e.key === 'Enter'且e.ctrlKey === false（排除 Ctrl+Enter 提交） - 调用
e.preventDefault()后，手动插入<br>或<div></div> - 关键：同时给
<form></form>加onsubmit="return false"或绑定空submit处理器，防止 fallback 提交
否则会出现「按键被阻止但表单仍提交」的双触发问题。
容易忽略的兼容性细节
不同浏览器对
e.submitter的支持程度不一，且表单内多个 submit 按钮时逻辑更复杂。- Firefox 在某些版本中对回车触发的
submitter返回undefined而非null，需用e.submitter == null安全判断 - Safari 对
contenteditable元素上的回车行为有延迟，keydown中阻止后可能仍触发submit，必须双重防护 - 如果表单用了
method="dialog"（如<dialog></dialog>内表单），回车行为完全独立，需单独处理
真正要拦住回车提交，核心不是“怎么监听按键”，而是“在哪一环切断提交链条”——
submit事件才是那个确定性的关卡。 - 给
