ajax表单提交需确保dom就绪、阻止默认行为、用formdata序列化、检查http状态码并禁用按钮防重复提交。
不能靠 <script></script> 标签位置“控制” AJAX 表单提交时机——它只负责加载代码，不参与事件流或 DOM 状态管理。 真正起作用的是 JS 执行逻辑与 DOM 加载、事件绑定的配合。常见错误是把 submit 监听写在 <script></script> 里却没等表单元素就绪，结果监听完全没生效。
为什么 script 标签放
浏览器解析 HTML 是从上到下同步进行的。<script></script> 在 中执行时，<form></form> 元素尚未被解析进 DOM，document.getElementById('myForm') 或 querySelector('form') 返回 null，后续的 addEventListener('submit', ...) 直接报错或静默失效。
- 现象：
Cannot read property 'addEventListener' of null - 解决方式：用
DOMContentLoaded包裹，或把<script></script>移到前 - 不推荐用
window.onload，它等所有资源（含图片）加载完，延迟更大
submit 事件监听必须调用 event.preventDefault()
表单默认行为是同步提交并跳转/刷新页面。哪怕你 JS 里发了 fetch() 或 XMLHttpRequest，只要没阻止默认行为，页面照样走掉——异步请求可能刚发出去就被中断，或者回调根本没机会执行。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 必须在事件处理器第一行写
event.preventDefault() - 不要依赖
return false：它只在 jQuery 里等价于 preventDefault + stopPropagation，原生 JS 中仅终止当前回调，不阻止默认提交 - 错误示范：
form.addEventListener('submit', () => { fetch(...); return false; })——return false无效
用 fetch() 提交表单数据要手动序列化
fetch() 不像 jQuery 的 .serialize() 那样自动打包表单字段。FormData 是最稳妥的选择，它能正确处理文件输入、同名多值（如复选框）、空值，并适配 multipart/form-data 和 application/x-www-form-urlencoded 两种后端常见格式。
- 推荐写法：
new FormData(formElement)，直接传<form></form>节点 - 避免手拼字符串：
username=' + encodeURIComponent(u) + '&password=...'易漏转义、难维护 - 如果后端只认 JSON，需先用
Object.fromEntries(new FormData(form))转对象再JSON.stringify()，但注意文件字段会丢失
错误处理不能只靠 catch()，还要检查 HTTP 状态码
fetch() 只在网络失败（如断网、DNS 错）时 reject；HTTP 4xx/5xx 响应仍算 fulfilled，必须手动判断 response.ok 或 response.status。
- 典型坑：
fetch('/login').then(r => r.json()).catch(e => console.error(e))—— 401 返回时不会进catch，而是进then，但r.json()可能因非 JSON 响应体抛错 - 安全写法：先
if (!response.ok) throw new Error(response.status)，再await response.json() - 服务端返回的错误信息（如
{ "error": "验证码错误" }）要显式提取并展示给用户，不能只弹"提交失败"
最容易被忽略的一点：表单禁用状态没同步。用户连续点击提交按钮时，若没在请求发出后立即将按钮设为 disabled，可能触发多次重复请求——后端未必幂等，前端 UI 也失去反馈。这个细节不在 <script></script> 标签位置里，而在事件处理器内部的执行顺序中。
