为什么 <button> 默认是 type="submit"？深入理解这一历史遗留的前端隐性规则
在日常前端开发中，<button> 是最常见的交互元素之一。这是一个容易被忽视但又需要被注意到的细节——在表单中不写 type 的按钮，会自动变成提交按钮 (submit) 。这一行为看似简单，却是许多意外提交、数据丢失和页面刷新的核心根源。
本文将从规范来源、历史原因、工程风险与最佳实践四个角度，全面解释这一默认行为背后的真相。
一、规范怎么定义 <button> 的默认行为？
根据 HTML Living Standard（WHATWG） 的规范：
当
<button>位于<form>中且未指定type属性时，浏览器必须将其视为type="submit"。
换句话说：
<button>按钮</button>
在表单内等同于：
<button type="submit">按钮</button>
这个默认值不是浏览器的特性，而是 标准明确规定的强制行为。
二、为什么要把默认值设计成 submit？
要理解这一“危险默认值”的由来，需要回到 Web 早期时代。
1. 与 <input> 时代的兼容性要求
在 <button> 标签出现之前，网页中的表单提交依赖：
<input type="submit">
当 <button> 被加入规范时，标准必须确保：
- 旧网站迁移到
<button>时不会出现行为变化 - 早期网页不会因为默认值不同而功能失效
因此，规范选择让它沿用 input 的默认提交行为。
2. 给非工程师提供“开箱即用”的表单
互联网早期的设计目标之一是：让非专业开发者也能轻松搭建功能性页面。
规范的目标是：
“放一个按钮，就可以提交表单。”
这在过去是非常合理的设计。
然而在现代前端组件化、单页应用与复杂交互的场景下，这种“历史兼容性”反而成了隐患。
三、为什么在现代工程中变成了常见 Bug？
1. 按钮点击会意外提交表单
开发者添加一个看似无害的按钮：
<button>展开详情</button>
放在 form 里，一点击页面就刷新：
- 输入内容丢失
- 表单提前提交
- 用户操作被中断
- 后端收到异常提交请求
这类问题在移动端更常见，因为误触更频繁。
2. 与前端框架结合时导致更多不可控问题
在 React、Vue、Svelte 等框架中：
- 提交动作可能优先于组件的状态更新
- 导致逻辑执行错乱
- 产生双重提交、导航中断等隐藏 Bug
这一点在团队开发中尤为容易踩坑。
3. 难以调试，因为开发者缺乏意识
许多开发者不知道 <button> 有默认 submit 行为。
当问题发生时，他们往往会从脚本、业务逻辑或框架找原因，而忽略了 HTML 的隐式规则。
四、现代前端的正确写法是什么？
必须遵循的最佳实践：
所有非提交按钮必须写明 type="button"
<button type="button">打开弹窗</button>
<button type="button">切换 Tab</button>
<button type="button">删除</button>
提交按钮则明确写：
<button type="submit">提交</button>
这样既明确用途，又杜绝隐性行为。
五、团队工程化如何避免此问题？
现代团队通常会通过 Lint 工具强制规范写法，例如 ESLint（React 项目）中：
react/button-has-type
启用后：
- 所有按钮必须显式声明 type
- 未声明时会在编译报错
- 从工具层面杜绝隐性风险
这已成为主流团队的默认配置。
六、这是一个必须牢记的“历史遗留陷阱”
<button> 默认行为是浏览器为了兼容旧时代网页而保留的机制。在当下，它反而成了前端工程中难以察觉却极具破坏性的隐性规则。
开发者必须了解：
<button>默认就是 submit- 在 form 中会自动触发提交
- 非提交按钮必须写
type="button"
这是前端工程中最典型的“历史原因导致的现代 Bug”。
