同步 ajax（async: false）应被完全弃用，因其会彻底冻结浏览器主线程，导致dom渲染、动画和用户交互全部停摆，现代标准已明确废弃，须改用promise或async/await解耦时序依赖。
同步 AJAX（async: false）会彻底冻结浏览器主线程，DOM 渲染、动画、用户交互全部停摆，这不是“慢”，而是“假死”。它在现代前端开发中应被完全弃用。
为什么 async: false 会让页面看起来像卡死
JavaScript 是单线程的，而同步 AJAX 会阻塞整个主线程：浏览器必须等请求完成、响应解析、回调执行完毕，才能继续处理任何其他任务——包括 DOM 更新、样式计算、布局、绘制，甚至鼠标悬停反馈。
- 即使你写了
$('#loader').show()，这行 JS 会被执行，但浏览器不会立即重绘 UI，因为渲染被挂起 - 滚动、点击、键盘输入全部无响应，DevTools 的 Performance 面板会显示一段超长的黄色（JS 执行）或紫色（Rendering）区块
- 该行为在所有浏览器中一致，且无法通过 CSS 动画、
requestAnimationFrame或setTimeout绕过
XMLHttpRequest 和 fetch 都不支持同步模式（除旧 IE）
现代标准已明确废弃同步请求：fetch 根本不提供同步选项；XMLHttpRequest 虽仍允许 open(method, url, false)，但 Chrome、Firefox 已在控制台报 DeprecationWarning，Safari 直接拒绝执行（返回 InvalidAccessError）。
- IE6–10 是唯一广泛支持同步 XHR 的环境，但这些早已退出主流支持范围
- jQuery 的
$.ajax({ async: false })底层仍是 XHR，因此继承全部缺陷，且掩盖了底层风险 - 若你依赖同步请求来“保证顺序”，说明逻辑耦合过紧——应改用
Promise链、async/await或事件驱动
替换同步 AJAX 的最小改动方案
不是简单把 async: false 改成 true 就完事，关键在于解耦调用方与数据就绪时机。
- 把原来写在 success 回调里的 DOM 操作，封装成独立函数，如
renderVendorList(data) - 移除所有依赖“请求返回后立即可用”的同步假设，例如不要在
fnLoadVendorData()返回值里 expect 数据 - 用
await fetch(...).then(r => r.json())替代 jQuery，避免隐式全局状态；若需兼容老环境，用XMLHttpRequest+Promise包装器 - 加载态必须显式管理：
$('#loader').show()放在请求发起前，$('#loader').hide()放在then或catch末尾
容易被忽略的副作用：表单提交和默认行为
很多同步 AJAX 出现在表单 onsubmit 处理中，用来“阻止提交 → 请求校验 → 手动跳转”，这种模式极易出错。
- 直接
return false或event.preventDefault()必须在异步流程开始前执行，否则表单可能重复提交 - 校验失败时，错误信息要靠 JS 插入 DOM，不能依赖服务端重定向后的 HTML 渲染
- 若原逻辑依赖“同步请求返回后再决定是否
submit()”，请改为event.preventDefault()+fetch().then(() => form.submit())
真正棘手的不是技术替换，而是那些散落在各处、靠“先发请求再读变量”维持的隐式时序依赖——它们不会报错，但会在异步化后随机失效。逐个函数加 console.time 和 console.timeEnd，比盲目加 await 更有效。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
