XMLHttpRequest需校验readyState===4且status>=200,fetch应配合AbortController实现超时控制,DOM更新须防XSS、事件丢失及内存泄漏,实际项目需统一处理loading、错误与防重提交。

XMLHttpRequest 基础写法:手动处理状态和响应
现代浏览器中,XMLHttpRequest 仍是底层核心,尤其在需要细粒度控制请求生命周期时不可替代。它不依赖第三方库,适合轻量场景或学习原理。
常见错误是忽略 readyState 和 status 的双重校验——只看 readyState === 4 但没检查 status === 200,结果服务器返回 404 或 500 时仍执行成功逻辑。
- 必须在
onreadystatechange中判断readyState === 4且status >= 200 && status -
responseType设为'json'可自动解析(IE10+),否则需手动JSON.parse(xhr.responseText) - 发送 JSON 数据时,记得设置请求头:
xhr.setRequestHeader('Content-Type', 'application/json')
const xhr = new XMLHttpRequest();
xhr.open('POST', '/api/update');
xhr.responseType = 'json';
xhr.setRequestHeader('Content-Type', 'application/json');
xhr.onreadystatechange = function() {
if (xhr.readyState === 4) {
if (xhr.status >= 200 && xhr.status < 300) {
document.getElementById('content').innerHTML = xhr.response.html;
} else {
console.error('请求失败:', xhr.status, xhr.statusText);
}
}
};
xhr.send(JSON.stringify({ id: 123 }));
fetch API:更简洁的 Promise 风格写法
fetch 是当前主流选择,语法更直观,但默认不带 cookie、不自动 reject 网络错误——这是最容易踩的坑。
它只在「网络异常」(如断网、DNS 失败)时 reject,而 HTTP 错误码(400/500)仍算 fulfilled,必须手动检查 response.ok 或 response.status。
立即学习“Java免费学习笔记(深入)”;
- 跨域请求需显式传
{ credentials: 'include' },否则 Cookie 不会发送 -
response.json()返回 Promise,要 await 或链式.then(),不能直接赋值 - 超时需自行封装(
AbortController是标准方案)
const controller = new AbortController();
setTimeout(() => controller.abort(), 5000);
fetch('/api/data', {
method: 'GET',
credentials: 'include',
signal: controller.signal
})
.then(response => {
if (!response.ok) throw new Error(`HTTP ${response.status}`);
return response.json();
})
.then(data => {
document.getElementById('list').innerHTML = data.items.map(i => `避免 DOM 操作引发的重复渲染或内存泄漏
无刷新更新的核心不是“发请求”,而是“安全替换内容”。直接用 innerHTML 赋值看似简单,但可能触发脚本重执行、事件监听器丢失、或 XSS 风险(若后端返回未转义 HTML)。
如果接口返回的是结构化数据(如 JSON),优先用 JS 构建 DOM;若必须插入 HTML,确保服务端已做 XSS 过滤,或前端用 textContent + 属性赋值代替。
- 动态添加的按钮/链接需重新绑定事件,或改用事件委托(
document.addEventListener('click', e => {...})) - 旧节点含定时器、WebSocket、或第三方插件实例时,应在替换前手动清理(如
clearTimeout、chart.destroy()) - 避免在循环中频繁操作
innerHTML,可先拼接字符串再一次性写入
实际项目中推荐的最小可用组合
纯原生开发不必追求封装大而全的请求库,但应统一错误处理、loading 状态和重试逻辑。一个实用底线是:每个请求至少有 loading 显示、失败 fallback、以及防重复提交保护。
- 按钮点击后立即
disabled = true,响应完成再恢复,防止用户连点多次 - 用
data-status属性标记区域状态(如data-status="loading"),CSS 控制 skeleton 效果 - 对非关键请求(如埋点、日志上报),可设
keepalive: true(fetch支持),避免页面卸载中断
复杂交互(如表单验证联动、乐观更新)需要状态管理配合,这时候就不是单纯“无刷新”能解决的了——得靠组件生命周期或状态同步机制兜底。











