前端表单处理中最容易踩的一个坑，就是把按钮放在 <form> 里却忽略它的默认 submit 行为。用户点击登录按钮后，异步请求刚发出，浏览器就刷新页面，参数丢失、控制台日志一闪而过。要理解这个问题，首先要明确：HTML 表单里的按钮在默认情况下并不只是普通的可点击元素，它承担着触发表单提交的角色。想要稳定地进行 JavaScript 交互，必须清楚默认提交的触发条件以及如何在合适的时机拦截它。

下面从触发链路、拦截方式和几个容易混淆的真实场景分别展开。

一、表单默认提交的触发链路

在一个标准的 <form> 元素中，<button> 标签如果没有显式设置 type 属性，浏览器会将其解析为 submit 类型。也就是说，<button>登录</button> 等价于 <button type="submit">登录</button>。点击该按钮时，浏览器会查找距离最近的祖先 <form>，然后触发表单的 submit 事件。若此时没有 JavaScript 阻止默认行为，浏览器会按照 action 属性的地址或者当前页面地址发起一次导航请求，最终导致页面刷新。

除了点击按钮，键盘回车同样会触发提交。当焦点位于 <input type="text"> 等文本输入框内时，按下回车键可能触发隐式提交。规则大致是：如果表单内存在提交按钮，回车会触发该按钮；如果只有一个非文本域输入框，也可能直接提交。对于搜索框、登录框这类场景，用户习惯按回车完成操作，因此只处理按钮点击往往不够。

<form id="loginForm" action="/login" method="get">
  <input type="text" name="username" placeholder="请输入用户名">
  <input type="password" name="password" placeholder="请输入密码">
  <button>登录</button>
</form>

上面的结构没有任何 JavaScript 介入时，点击登录按钮或输入框内按回车，都会把 username 和 password 拼接到地址栏，并刷新整个页面。这个行为是 HTML 规范的一部分，但与现代单页交互的预期完全不匹配。

二、阻止默认提交的常用方法

第一种方式是直接改变按钮的类型。把按钮声明为 <button type="button">，浏览器就不会把它当作提交按钮，点击后也不会触发表单提交。这种方式适用于按钮本身不承担提交职责、只需要绑定 click 事件来做异步处理的场景。

<form id="loginForm">
  <input type="text" name="username">
  <input type="password" name="password">
  <button type="button" id="loginBtn">登录</button>
</form>

document.getElementById('loginBtn').addEventListener('click', function () {
  var username = document.querySelector('input[name="username"]').value;
  var password = document.querySelector('input[name="password"]').value;
  // 执行异步请求，页面不会刷新
  fetch('/api/login', {
    method: 'POST',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify({ username: username, password: password })
  }).then(function (response) {
    return response.json();
  }).then(function (data) {
    console.log(data);
  });
});

这种方式简单直接，但按钮类型改变后，表单内部的回车提交行为也会受到影响。如果仍希望用户按回车时自动触发登录，还需要额外监听键盘事件，或者在保留 submit 按钮的前提下采用事件拦截方案。

第二种方式是在 submit 事件中调用 event.preventDefault() 方法。它可以阻止浏览器继续执行默认的导航行为，同时不影响事件本身的传播。这也是最常用的做法，因为表单仍然保留语义上的提交能力，原生校验、回车提交等行为都能正常工作。

document.getElementById('loginForm').addEventListener('submit', function (e) {
  e.preventDefault();
  var formData = new FormData(this);
  fetch('/api/login', {
    method: 'POST',
    body: formData
  }).then(function (response) {
    return response.json();
  }).then(function (data) {
    console.log(data);
  });
});

第三种方式是在 <form> 标签上使用 onsubmit 属性并返回 false。它的效果与 preventDefault 类似，但会依赖返回值来决定是否阻止默认行为。需要注意的是，如果 onsubmit 内部的函数发生异常，或者返回了 undefined，表单仍然可能继续提交。因此这种写法更适合简单场景，复杂业务逻辑建议使用 addEventListener。

<form id="loginForm" onsubmit="return handleSubmit(event)">
  <input type="text" name="username">
  <input type="password" name="password">
  <button type="submit">登录</button>
</form>

function handleSubmit(e) {
  e.preventDefault();
  // 处理异步提交
  return false;
}

比较这几种方式：修改按钮类型最省事，但如果表单内还包含其他提交入口，容易漏掉；preventDefault 最规范，能保留提交语义，同时可以通过 submit 事件统一处理点击按钮、回车等所有触发路径；onsubmit 返回 false 语法直接，但错误处理能力较弱。实际项目里可以优先选择 submit 事件加 preventDefault。

三、容易混淆的实战场景

第一个场景是多个按钮共用一个表单。比如后台编辑页可能同时有保存草稿和正式发布两个按钮。如果都使用普通按钮或者都使用 submit 类型，没有区分触发源，很容易出现逻辑混乱。可以通过给按钮设置不同的 name 和 value，在 submit 事件中读取 submitter 属性来判断用户点击了哪一个按钮。

<form id="editForm">
  <textarea name="content"></textarea>
  <button type="submit" name="action" value="draft">保存草稿</button>
  <button type="submit" name="action" value="publish">正式发布</button>
</form>

document.getElementById('editForm').addEventListener('submit', function (e) {
  e.preventDefault();
  var action = e.submitter ? e.submitter.value : 'draft';
  if (action === 'publish') {
    // 走发布流程
  } else {
    // 走草稿流程
  }
});

第二个场景是表单内同时存在原生校验。使用 required、pattern 等属性时，浏览器会先进行约束验证，验证通过后才会触发 submit 事件。如果我们在 click 事件里就执行异步请求，就可能绕过原生校验，导致空数据被提交。因此异步提交逻辑放在 submit 事件里更稳妥，原生校验完成后再执行，数据质量更有保障。

第三个场景是按回车误触提交。比如表单里有一个搜索输入框，用户输入关键词时按回车想要触发联想，但实际却导致整个页面刷新。这时可以在 keydown 事件中判断按键是否为回车，并调用 preventDefault 阻止默认提交；但如果用户希望用回车提交，则应该只对特定按键或组合键做拦截。对于搜索联想，更常见的做法是把输入框放在一个不包含提交按钮的表单中，或者直接不用 form 包裹输入框。

第四个场景是前端框架里的处理差异。在 Vue 中，可以使用 v-on:submit.prevent 修饰符来阻止默认提交，React 中则在 onSubmit 回调里调用 e.preventDefault()。框架通常会把合成事件统一处理，但底层仍然是浏览器原生行为，理解这一点有助于排查偶发的页面刷新问题。

// React 示例
function LoginForm() {
  const handleSubmit = (e) => {
    e.preventDefault();
    // 异步请求
  };
  return (
    <form onSubmit={handleSubmit}>
      <input name="username" />
      <button type="submit">登录</button>
    </form>
  );
}

上面的 React 代码只是说明处理位置，关键是阻止默认事件必须发生在提交回调的第一时间。若忘记调用 preventDefault，即使状态更新再快，浏览器也可能会先执行页面跳转，导致前端逻辑被打断。

四、从事件机制角度理解 preventDefault 与 return false

要彻底理解为什么某些写法有效、某些写法无效，还需要回到 DOM 事件模型。submit 事件从触发表单开始，经过捕获、目标、冒泡三个阶段。preventDefault 只作用于默认行为，不会阻止事件继续传播。而 return false 在原生事件属性中同时具有阻止默认行为和阻止冒泡的效果，但在 addEventListener 中却没有任何作用。

很多页面刷新问题来自于对这两者的混用。例如在 addEventListener 的回调里返回 false，并不能阻止默认提交。必须显式调用 event.preventDefault()。另一个常见误区是以为所有按钮点击都会冒泡到 document 后取消就可以了，但如果事件已经完成默认行为，冒泡阶段再阻止已经来不及。因此，监听 submit 事件并在回调第一行调用 preventDefault，是处理这类问题的最可靠方式。

此外，表单内输入框的 keypress、keydown 事件与提交事件的顺序也值得注意。按回车时，浏览器通常先触发 keydown，再触发 keypress，最后触发表单的 submit。若在 keydown 中阻止默认行为，可以阻断后续提交动作；若在 keypress 中处理，则需要针对不同浏览器做兼容。日常开发中以 submit 事件统一拦截，比在键盘事件里做零散判断更稳定。