最推荐方案是为输入框绑定 keydown 事件监听 Enter 并调用按钮 click()，或直接使用 form 的 submit 事件；必须加 event.preventDefault()，且所有非提交按钮需显式设 type="button"。
输入框 keydown 监听 Enter 触发按钮点击
直接给搜索输入框绑定 keydown 事件，检测 event.key === 'Enter'，再手动调用目标按钮的 click() 方法，是最直白、兼容性最好的方式。它不依赖表单结构，适合你当前已存在独立 <input> 和 <button id="submit"> 的场景。
常见错误是只写 keyCode === 13 而忽略现代标准，或漏掉 event.preventDefault() 导致页面跳动或重复提交。
- 必须用
event.preventDefault()—— 否则在<textarea>中会换行，在<form>内会触发默认提交 - 优先用
event.key === 'Enter'，keyCode已废弃，仅作降级兼容（如event.keyCode === 13 || event.key === 'Enter'） - 确保输入框有焦点：用户需先点击或用
.focus()主动获取，否则事件不会触发 - 若页面有多个输入框，统一用
document.querySelectorAll('input, textarea')批量绑定，比单个onkeydown属性更易维护
form 元素原生 submit 事件更语义化
如果你的搜索输入框和按钮本就包裹在 <form> 标签内，直接监听 form 的 submit 事件，比监听键盘更可靠。浏览器对回车、点击 submit 按钮、软键盘“搜索”按钮等所有提交方式一视同仁，且天然支持无障碍访问。
容易踩的坑是忘记阻止默认行为，导致页面刷新或跳转到 action 地址。
立即学习“前端免费学习笔记（深入）”；
- 必须在事件处理函数中调用
event.preventDefault()，否则表单仍会按 HTML 默认逻辑提交 - 按钮要用
type="submit"，且不能被disabled或readonly禁用，否则无法触发submit事件 - 输入框建议设为
type="search"，移动端软键盘会显示“搜索”图标，提升体验 - 不要在
form上写onsubmit="return false"这类内联写法，改用addEventListener('submit', handler)更清晰
为什么你的 Cancel 按钮也被回车触发了？
这不是 JS 写错了，而是 HTML 默认行为：未声明 type 的 <button>，浏览器一律当 type="submit" 处理。只要它在 <form> 内，又是 DOM 中第一个可提交按钮，回车就会点它——哪怕你本意只是“取消”。
这个坑几乎每个前端都踩过，修复成本极低，但影响极大。
- 立刻检查所有非提交用途的按钮，显式加上
type="button"，例如：<button type="button" name="Cancel">Cancel</button> - 别信“我删了
type="submit"就安全了”——没写type就等于写了type="submit" - 动态生成按钮时（如 JS
createElement('button')），记得同步设置button.type = 'button' - 框架项目（React/Vue）里也要写全
type="button"，JSX 或模板中不写，编译后照样是默认 submit
要不要用 keypress 或全局 document 监听？
不用。这两个方案现在基本属于历史遗留写法，问题明确：
keypress 对 Enter 支持不稳定，Chrome/Firefox 表现不一致，MDN 已标记为废弃；全局监听 document 的 keydown 则要自己判断事件源是否为可编辑元素，还要过滤掉 Ctrl+Enter、Alt+Enter 等组合键，徒增复杂度且易出错。
- 坚持用
addEventListener('keydown', ...)绑定到具体输入框或form上，目标明确、逻辑干净 - 如果真需要
Ctrl+Enter提交（比如评论框），就在同一个监听函数里加event.ctrlKey判断，不要另起一套 - 移动端软键盘的“搜索”按钮，只有
type="search"+<form>+submit事件才能正确识别，其他方式大概率失效
type 这件事——它不报错、不警告，只在用户按下回车时悄悄执行错误逻辑，排查起来反而比 JS 错误更耗时间。 
