form默认支持回车提交，无需监听keydown；仅textarea需拦截enter换行；submit事件是跨平台唯一可靠提交入口，应避免手动调用form.submit()或依赖key事件。
form 默认就支持回车提交，别瞎监听 keydown
绝大多数情况下，form 元素根本不需要你写 keydown 监听器来“实现”回车提交——浏览器原生支持，且行为稳定。只要满足两个条件：表单内至少有一个可聚焦的输入控件（如 <input type="text">、<textarea></textarea>），且存在一个 type="submit" 按钮（或未设 type 但被浏览器默认为 submit 的 <button></button>），用户在任意输入框里按 Enter，就会触发 submit 事件。
常见错误是给 <input type="text"> 绑定 keydown 并调用 form.submit()，这不仅多余，还会绕过 submit 事件监听器，导致 e.preventDefault() 失效，页面意外刷新。
- 不要在
<input>上监听Enter后手动触发提交逻辑 - 不要用
form.submit()模拟提交——它不触发submit事件 - 若表单里只有单个
<input type="text">且无 submit 按钮，浏览器仍会提交（这是历史兼容行为）
textarea 里按回车要换行？只拦截它的 keydown
唯一需要干预 Enter 行为的场景，就是 <textarea></textarea>。用户期望按 Enter 插入换行符，而不是提交表单。这时必须精准拦截：只在 textarea 的 keydown 事件中判断 e.key === 'Enter'，且排除 Shift、Ctrl 等修饰键，再调用 e.preventDefault()。
切记：不要对 <input type="text"> 做同样操作，否则破坏默认提交体验；也不要监听整个 form 或 window，那样会误杀其他输入框的合法提交。
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 拦截目标必须是
textarea元素本身，而非父级form - 检查
!e.shiftKey && !e.ctrlKey && !e.altKey，避免影响Shift+Enter等组合键 - 手动插入换行符时，注意维护光标位置（
selectionStart/selectionEnd）
多个 submit 按钮共存时，谁被回车触发？
当表单内有多个 type="submit" 按钮，回车只会激活 DOM 中**第一个**（按源码顺序）的按钮。它的 click 事件会执行，同时触发 form 的 submit 事件——两者并存，不是替代关系。
容易踩的坑是给多个按钮都加 onclick，却没意识到回车只走第一个。更危险的是把非提交按钮（如 type="button"）漏写 type 属性，浏览器在不同环境可能默认为 submit，造成意外交互。
- 显式声明所有按钮的
type：提交用type="submit"，普通操作用type="button" - 避免依赖 CSS 隐藏 submit 按钮（如
display: none）来“禁用”回车提交——它仍参与 DOM 顺序判定 - 如需动态控制默认提交按钮，可用
form.querySelector('button[type="submit"]')手动聚焦，而非靠 DOM 顺序
移动端软键盘的“回车”不可信，submit 事件才是唯一入口
Android 键盘上的“回车”常被映射为“搜索”“发送”，iOS 则多为“前往”，这些按键不一定发出 e.key === 'Enter'，有些直接触发 submit，有些则完全静默。试图靠监听 keydown 捕获所有软键盘提交动作，注定失败。
真正跨平台可靠的方案，只有一个：所有提交逻辑都绑定在 form 的 submit 事件上，并在回调里统一调用 e.preventDefault()。这个事件能捕获所有来源的提交意图——物理键盘、软键盘、语音输入、甚至辅助技术触发的提交。
- 不要依赖
e.key或e.keyCode判断是否提交 - 不要在
button.click()里做核心逻辑，而应放在form.submit回调中 - 实测软键盘行为时，重点验证
submit事件是否被触发，而非看keydown是否捕获到 Enter
type 属性的缺失和软键盘行为的不可预测性——这两点不处理，光写一堆 keydown 监听器，只会让问题更隐蔽。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
