是，button默认type为submit会提交表单；显式设type="button"才无行为；阻止提交应优先用submit事件监听或click中preventDefault()；button与input[type="submit"]在内容嵌套、值提交和无障碍方面存在差异。
button 默认行为是提交表单吗
不是所有 <button> 都会触发提交，关键看它的 type 属性。没显式声明时，浏览器按 HTML 规范默认设为 type="submit"——这正是多数人踩坑的源头。
常见错误现象：<button>点击就刷新页面</button>，控制台没报错，但表单意外提交了。
- 显式写成
<button type="button">才真正“无行为”，适合做纯 JS 触发按钮 -
<button type="submit">显式声明后，行为可预测，也方便 CSS 选择器定位（如button[type="submit"]） - 在表单内放
<button>却忘了设type，不同浏览器都认作 submit，但开发者常误以为它和<input type="button">一样“安静”
阻止 button 提交但保留点击事件的正确方式
别在 onclick 里直接写 return false，更别用 event.preventDefault() 后又手动调 form.submit()——除非你真需要绕过原生校验逻辑。
典型场景：点击按钮先校验字段，通过才提交；或点击后弹窗确认，再决定是否提交。
立即学习“前端免费学习笔记（深入）”；
- 监听
click事件时，event.preventDefault()足够阻止提交，且不影响其他逻辑 - 监听
submit事件（绑定在<form>上）才是拦截提交的正统位置，能统一处理所有提交入口（包括回车、JS 调用submit()等） - 如果用了
form.requestSubmit()，它会触发submit事件并尊重required等原生校验；而直接调form.submit()会跳过所有校验和事件
button 与 input[type="submit"] 的实际差异
两者都能提交，但渲染、可访问性和 DOM 行为有细微差别，影响调试和维护。
错误认知：“它们完全等价，换着用没问题”。实际上：
-
<input type="submit">是自闭合标签，无法嵌套内容或 HTML 元素；<button type="submit">支持子元素（比如<span></span>或图标），更适合复杂 UI - 部分旧版 IE 对
<button>的value属性读取不一致：表单提交时，<button>发送的是innerHTML（或textContent），而<input>固定发value属性值 - 无障碍方面，
<button>更易被屏幕阅读器识别为可操作控件，尤其当内容含富文本时
表单内多个 button 导致误提交的排查思路
一个表单里混用多个 <button>，却只给其中一个加了 type="button"，其余没设 type，结果点哪个都提交。
这不是 bug，是规范行为，但极易被忽略。
- 用浏览器开发者工具检查每个
<button>的 computedtype值，别只看源码有没有写 - 全局搜索
<button>，逐个补上type属性，宁可啰嗦也要明确 - 若项目用框架（如 React/Vue），注意 JSX/模板中动态生成的
<button>是否遗漏type，尤其是条件渲染分支 - 服务端收到重复或意外的 POST 请求，优先查前端是否有未设
type的<button>，比查网络请求更高效
最麻烦的不是写错，而是写对了却忘了检查所有 button 实例——尤其在复用组件、合并他人代码或快速迭代时，type 属性最容易被当成“无关紧要的细节”跳过验证。
