button默认type为submit，表单内非提交按钮必须显式设置type="button"以阻止默认提交行为，否则将导致意外跳转或请求失败。
button 默认 type 是 submit，不是 button
只要 <button> 在 <form> 里，又没写 type 属性，浏览器就当它是 type="submit"。哪怕你只打算用它执行 JS（比如关弹窗、刷新验证码），点一下照样触发表单提交——页面跳转、弹窗消失、请求发不出去，全是因为这个“默认值”在作祟。
常见错误写法：<button class="close">×、<button onclick="reloadCaptcha()">刷新</button>。它们看着像普通按钮，实际是隐形提交按钮。
- 检查所有
<button>是否显式写了type="button"（非提交用途）或type="submit"（真正要提交） - 别依赖 CSS 类名判断行为，
class="btn-cancel"不等于type="button" - Layui、Bootstrap 等框架的文档常忽略这点，但底层 HTML 规范没商量余地
表单内非提交按钮必须加 type="button"
加 type="button" 是最轻量、最可靠的解法。它直接切断按钮与表单的语义关联，JS 绑定 click 事件后，执行完就不会再走默认提交流程。
错误示例：<form><button onclick="hideError()">关闭</button></form> → 点击后 error box 刚隐藏就刷新了。
立即学习“前端免费学习笔记（深入）”；
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
正确写法：<button type="button" onclick="hideError()">关闭</button>。
- 不需要额外写
event.preventDefault()，type="button"已天然阻止默认行为 - 对可访问性友好：屏幕阅读器会正确识别该按钮不参与表单提交
- 比 JS 拦截更早生效——连 submit 事件都不会触发，避免竞态问题
模态框里容易漏掉 type 的按钮类型
注册弹窗、密码重置弹窗、编辑弹窗……这类动态插入的表单区域，最容易出现“按钮没加 type”的情况。尤其当弹窗内容是字符串拼接或模板渲染时，type 属性极易被遗漏。
典型陷阱：layer.open({ content: `<form>...<button>取消</button></form>` }) —— 这里的 <button> 没 type，点取消就提交整个表单。
- 用浏览器 Elements 面板展开弹窗 DOM，逐个检查
<button>是否带type - 如果弹窗内容由 JS 拼接，建议统一封装按钮生成逻辑：
function makeButton(text, type = 'button') { return `<button type="${type}">${text}</button>`; } - 注意
<input type="button">同样安全，但它不能包裹 HTML 内容（如图标 SVG），不如<button type="button">灵活
submit 按钮和 button 按钮混用时的 DOM 位置风险
一个表单里既有 type="submit" 按钮，又有多个 type="button" 按钮，看起来没问题。但如果 submit 按钮被 JS 动态移出 <form>（比如为了样式隔离挪到 modal footer 外部），它就彻底失效了——点击毫无反应，控制台也无报错。
验证方法：选中 submit 按钮，在 Elements 面板里往上找最近的 <form> 开始标签，确认它是否在该 <form> 的闭合标签之内。
- 不要靠视觉布局判断，DOM 树层级才是唯一依据
- 使用
document.querySelector('form').contains(submitBtn)在控制台快速验证 - 动态插入按钮时，优先用
form.appendChild(btn)而非parentDiv.appendChild(btn)，避免脱离上下文
<button> 的 type 属性都不是可选项，而是语义契约——浏览器按它行事，JS 无法覆盖。最容易被忽略的，恰恰是那些“本不该提交”的按钮。 
