浏览器警告同步AJAX请求必须立即替换，因其会导致页面卡死；定位方法是检查Network中Initiator为XMLHttpRequest.send且状态为blocked的请求，或Console中带文件行号的警告；替换方案为用fetch+async/await或jQuery异步方法，并在layui弹窗中避免直接submit后close，改用postMessage通信。
这是浏览器明确警告你用了已被废弃的同步 AJAX 请求，必须立刻改掉——它不是“能用就行”的小问题，而是会导致页面卡死、用户无法操作的严重缺陷。
为什么 layui 项目里还会冒出这个警告
layui 本身不主动发同步请求，但你或第三方代码可能在以下位置写了 xhr.open(..., false)：
- 手写的原生
XMLHttpRequest，第三个参数传了false - 某些老旧封装的工具函数（比如带
sync: true选项的请求方法） - jQuery 的
$.ajax({ async: false })（虽已过时，但旧项目仍有残留） - 直接调用表单
submit()后又紧跟location.reload()或parent.layer.close()，触发浏览器隐式同步行为（尤其在 iframe 弹窗中）
怎么快速定位到哪行代码在发同步请求
打开 Chrome DevTools → Network 标签页 → 勾选 “Disable cache” → 刷新页面 → 看是否有请求的 “Initiator” 列显示为 XMLHttpRequest.send，且状态栏提示 “(blocked)” 或 “(pending)”；再切到 Console，警告信息里会带具体文件名和行号，点进去就能看到类似这样的代码：
var xhr = new XMLHttpRequest();
xhr.open('GET', '/api/data', false); // ← 这里 false 就是罪魁祸首
xhr.send();
注意：fetch 完全不支持同步模式，所以只要看到这个警告，100% 是 XMLHttpRequest 或 jQuery 的 $.ajax 在作祟。
替换方案：三步改成安全异步请求
把原来同步逻辑拆成三段：发请求 → 处理响应 → 更新 UI/关闭弹窗。不要试图“等它回来”，要“告诉它回来后做什么”：
- 用
fetch+async/await替代原生xhr：把函数标为async，用await fetch(url)获取响应，再await res.json() - 如果还在用 jQuery，把
$.ajax({ async: false })改成$.get()或$.post()，并把后续逻辑移到success或complete回调里 - 在 layui 弹窗中，千万别写
form.submit(); parent.layer.close(index);—— 改成先fetch提交，finally里关层，或用btnAsync: true配合that.loading(true)
特别注意 iframe 弹窗里的陷阱
在 type: 2 的 iframe 层里，最容易误触同步行为：
- 子页面里直接写
document.getElementById('myform').submit()，浏览器会尝试同步提交并跳转，同时冻结父页面 - 父页面点击确定按钮后，没等子页面请求返回就执行
parent.layer.close(index)，导致请求被中断（Network 面板里根本看不到请求） - 正确做法是：子页面用
fetch提交，成功后发消息给父页parent.postMessage({ type: 'submit-success' }, '*')；父页监听消息再关层
真正难处理的不是“怎么发请求”，而是“怎么让 UI 状态和异步流程严丝合缝”。比如按钮 loading 态、失败后恢复可点击、关闭前校验未保存数据——这些细节一旦漏掉，用户就会觉得“点了没反应”或“点了两次才生效”。
