javascript中ajax默认异步，设open()第三个参数为false可实现同步请求，但已被chrome 80+等现代浏览器在主线程中禁用，会导致ui假死、违背响应式设计且不兼容promise/async-await，必须改用fetch+await等异步方案。
JavaScript 中 Ajax 默认是异步的，但可以通过设置 async: false 实现同步请求，从而阻塞后续 JavaScript 执行，直到请求完成。不过这种做法已被现代浏览器弃用，不推荐在生产环境中使用。
同步 Ajax 的基本写法（已废弃）
使用原生 XMLHttpRequest 时，将第三个参数设为 false 即可开启同步模式：
- 必须使用
open()的第三个参数为false - 调用
send()后，JS 线程会暂停，页面 UI 也会卡住，直到响应返回或超时 - 不能在主线程中用于用户交互场景（如点击按钮后发同步请求），否则页面完全无响应
为什么同步 Ajax 被禁止？
现代浏览器（Chrome 80+、Firefox、Edge）已在主线程中禁用同步 XMLHttpRequest，尤其在非 Worker 环境下会直接抛出异常：
- 导致页面假死，违背 Web 的响应式设计原则
- 无法与 Promise、async/await 共存，破坏现代异步编程模型
- 在页面卸载、iframe 或某些安全上下文中会被静默拒绝
替代方案：用异步 + 控制流程实现“逻辑阻塞”
真正需要等待结果再执行下一步时，应改用异步方式配合控制流处理：
- 用
fetch()+await在 async 函数中“看起来像同步”，实际不阻塞渲染 - 把后续操作放在
then()或try/catch块中，保证顺序执行 - 如需多步依赖，可用
Promise.all()或串行 await 链
特殊情况下的“伪同步”处理
极少数场景（如旧系统迁移、特定调试需求）仍想模拟同步效果，可考虑：
- 禁用触发按钮，显示 loading，等异步完成后再恢复交互
- 用
top.location.href或表单提交跳转，由服务端渲染承接等待逻辑 - 在 Web Worker 中发起同步请求（Worker 线程允许同步 XHR，但无法直接操作 DOM）
本质上，同步 Ajax 是过时的设计，现代开发应拥抱异步、避免 UI 阻塞。合理使用 await 和状态管理，比强行同步更健壮、更可维护。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
