模态框验证失败不关闭的根源是未调用event.preventDefault()阻止表单默认提交，导致页面刷新清空JS状态；需同时设置novalidate属性、动态添加.was-validated类、服务端控制按钮type，并确保data-bs-target准确匹配。
验证失败时模态框不关闭，不是 js 没生效，而是你没让浏览器“知道”该阻止默认行为——表单仍按原生逻辑提交并刷新页面，模态框自然来不及关就消失了。
form.submit 里必须调用 event.preventDefault()
这是最常被跳过的一步。只要没在 submit 回调里阻止默认提交，浏览器就会立刻 reload 页面，所有 JS 状态（包括模态框）瞬间清空。
- 错误写法：
$('#myForm').on('submit', function() { /* 只做校验，没 prevent */ }); - 正确写法：
$('#myForm').on('submit', function(e) { e.preventDefault(); /* 后续校验+AJAX */ }); - 如果用了 Bootstrap 5 原生验证，
form.checkValidity()返回false后，也得靠preventDefault()拦住提交，否则红边框刚出来，页面就刷没了
novalidate 和 .was-validated 必须同时存在
漏掉任一个，都会导致验证样式不显示、反馈不触发，用户根本看不出哪错了，自然反复点提交——模态框看起来“卡住”，其实是表单在静默失败后又刷新了。
-
novalidate要写在<form>标签上，不是某个 input；它禁用浏览器弹窗，让 Bootstrap 的.invalid-feedback有机会显示 -
.was-validated不能一开始就加在 form 上，得在 submit 事件里手动加：form.classList.add('was-validated')，否则一进页面所有字段全标红 - AJAX 提交前务必先调
form.checkValidity()，别只看 class 名——class 是视觉层，checkValidity()才是真实校验入口
服务端验证失败后，按钮不能仍是 type="submit"
这是最容易被忽略的后端配合点。Laravel、ThinkPHP 或手写 PHP 渲染页面时，如果服务端返回带错误的表单 HTML，但提交按钮还是 type="submit"，用户点一下就再次触发原生提交——模态框刚弹出半秒，页面就刷新了，像“闪退”。
- 服务端要根据是否有错误，动态输出按钮类型：
type="button"（验证失败）或type="submit"（验证通过） - 前端 JS 不该试图“动态启用/禁用”按钮，因为服务端重渲染后状态丢失，且绕过 JS 就能直接提交
- 模态框里的表单，最好整个 DOM 都由服务端控制输出，避免前后端对按钮语义的理解错位
多个模态框共存时，data-bs-target 不能重复或写错
当页面有多个模态框（比如编辑弹窗 + 删除确认），若不同按钮的 data-bs-target 指向同一个 id，或者 id 写错（如写成 itemid 或拼错），JS 初始化会失败或绑定错乱，导致点击后无响应、关闭逻辑失效、背景残留。
- 检查每个触发按钮的
data-bs-target="#xxx"是否与对应<div class="modal" id="xxx">的id完全一致（注意大小写和符号） - 避免在 AJAX 加载内容后重复初始化 Modal 实例，优先用
bootstrap.Modal.getInstance(el)检查是否存在，再决定是否新建 - 移动端 iOS Safari 对
data-bs-backdrop="static"响应不稳定，若需禁点击背景，建议同时加keyboard: false并在 show 后补一句$('.modal-backdrop').css('pointer-events', 'auto')强制接管
真正卡住模态框的，往往不是某一行 JS 写错，而是表单语义（type="submit"）、HTML 属性（novalidate）、CSS 类（.was-validated）和服务端输出逻辑这四者没对齐。少一个，验证就断链，模态框就“假死”。
