没有性能差异，二者底层处理路径相同，差异仅在于是否触发表单提交生命周期；所谓“卡顿”实为页面刷新、ajax中断或状态丢失等行为副作用，并非执行速度问题。
type="button" 和 type="submit" 有性能差异吗？
没有。二者在渲染、事件分发、内存占用或执行速度上完全一致——浏览器对 type="button" 和 type="submit" 的底层处理路径相同，差异仅在于**是否触发表单提交生命周期**。所谓“性能对比”是个伪命题，真正影响体验的是行为误触发带来的副作用，比如页面刷新、AJAX 中断、状态丢失。
为什么你会觉得 type="submit" “更慢”或 “卡一下”？
这不是性能问题，而是行为干扰：
- 点击
type="submit"后，浏览器立即开始收集<form></form>内所有带name的字段，序列化为表单数据 —— 这个过程极快，但紧随其后的是页面跳转或刷新（哪怕action=""或没写action） - 如果你绑了
onclick但没阻止默认行为，JS 函数可能刚执行一半，页面就已卸载，导致 console.log 不出现、网络请求被取消、React state 更新丢失 - 在 SSR 或模板中漏写
type，上线后部分按钮悄悄变成type="submit"，引发偶发性白屏或 404，容易被误判为“接口慢”或“JS 加载失败”
哪些地方真会影响性能？
和 type 值本身无关，但常被连带误配：
-
type="submit"触发submit事件，若你在<form></form>上监听了复杂的校验逻辑（如同步遍历大量 DOM 节点、正则匹配长文本），这部分 JS 才是瓶颈 -
type="button"虽不触发表单流程，但如果 onclick 里写了重型操作（如生成大体积 PDF、解析 megabytes 级 JSON），照样卡顿 - 用
type="submit"配合未设event.preventDefault()的onsubmit，会导致两次提交：一次原生（刷新），一次 JS 手动调用（如fetch），白白多发一次请求
别忽略的语义陷阱
浏览器不会因为 type="button" 就少解析 DOM，也不会因 type="submit" 多占内存——但错误的 type 会让键盘交互失控：
- 按 Enter 键时，焦点在任意可提交控件（如
<input>）上，浏览器会自动触发最近的type="submit"按钮；若你本意是清空搜索框却用了type="submit"，用户敲回车就提交空表单 -
type="reset"看似无害，但它会强制重置所有字段到 HTML 初始值（defaultValue），对 React/Vue 组件内由 JS 控制的值完全无效，还可能触发意外的 UI 闪烁 - 非法
type值（如type="primary"或空字符串）在<form></form>内会被降级为submit，这种隐式行为比显式写错更难排查
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
