表单提交后页面刷新但数据未达后端，主因是submit默认行为触发跳转；应禁用默认行为、检查Network中XHR/Fetch请求、确认Content-Type是否误设、正确监听file的change事件、避免innerHTML插入file输入框、使用事件委托处理动态元素。
表单提交后页面刷新但数据没传到后端
这是最常被当成“表单不工作”的假象——实际是 submit 事件触发了默认行为，页面跳转/刷新，导致你根本没机会看到请求是否发出、有没有报错。
- 先用浏览器开发者工具的 Network 面板过滤
XHR或Fetch，看有没有发出去；如果只有document类型请求，说明压根没走 AJAX，只是传统表单提交 - 在
form元素上加onsubmit="return false;"临时禁用默认提交，再检查 JS 是否执行到发送逻辑 - 用
event.preventDefault()替代return false更稳妥，尤其当事件监听是用addEventListener绑定的时候 - 后端接收不到数据，也可能是
Content-Type不匹配：原生fetch发FormData时不要手动设Content-Type，浏览器会自动加 boundary；设错了反而导致后端解析失败
input type="file" 选完文件没反应
不是 DOM 没更新，而是你没监听对事件——change 是唯一可靠触发点，click 或 input 在文件选择器场景下基本无效。
-
input[type="file"]的value只读且只含文件名（不含路径），别指望它返回完整路径 - 要读文件内容，必须用
FileReader或直接把input.files[0]塞进FormData；直接取.value只能做非空校验 - 移动端 iOS Safari 对
multiple支持不稳定，单文件场景更保险；如需多图上传，建议逐个触发或用webkitdirectory（仅限桌面 Chrome） - Vue/React 等框架里，别依赖
v-model或受控组件绑定file输入——它天生不受控，必须用ref+change事件手动抓取
表单验证提示不显示或样式错乱
浏览器原生验证（required、pattern、type="email"）和自定义 JS 验证混用时，容易互相覆盖状态。
- 调用
reportValidity()可主动触发原生校验并显示气泡提示；但若之前调过setCustomValidity('')，得先setCustomValidity('')清空才能恢复原生行为 - CSS 伪类
:valid/:invalid只响应原生验证，对 JS 手动setCustomValidity的结果不会实时更新，除非再触发一次校验 - 用
checkValidity()判断是否通过，返回布尔值；但它不触发 UI 提示，适合配合自定义错误文案使用 - 某些 UI 库（如 Bootstrap）会重置表单元素的
outline和box-shadow，导致原生验证高亮失效，得手动补.form-control:invalid { box-shadow: 0 0 2px red; }
动态添加的表单元素无法触发事件或验证
DOM 节点是后来插入的，但事件监听器早就在页面加载时绑定了，自然捕获不到。
立即学习“前端免费学习笔记（深入）”；
- 别对每个新
input单独addEventListener，改用事件委托：监听form的change或input，再用event.target.matches('input[data-validate]')过滤 - 动态插入的
input如果带required，得等插入 DOM 后再调用form.checkValidity()，否则它不计入整体校验 - 用
innerHTML插入含type="file"的片段会重置已选文件，必须用document.createElement+appendChild，或插入后立刻重新绑定change监听 - React/Vue 中动态渲染表单，确保 key 值唯一且稳定，否则框架可能复用旧节点，导致事件监听丢失或状态错乱
表单的问题，八成出在“你以为它在运行，其实它早就断连了”——比如监听器绑在父容器却忘了事件冒泡，比如验证逻辑写在 DOMContentLoaded 里却没考虑后续动态插入。留心那些没报错却静默失效的环节，比解决红字错误更花时间。
