xhr readystate 是分0–4五级的渐进式状态机，需结合各状态真实含义与边界条件精准监控：0未初始化，1连接建立但未发包，2响应头就绪可校验status，3响应体流式接收中需防乱码，4请求结束但须配合status判断成败。
XHR 的 readyState 是一个只读整数，反映请求所处的生命周期阶段。它不是简单的“成功/失败”二值状态，而是分五级（0–4）的渐进式过程。利用这五个状态构建状态机监控，关键在于理解每个状态的真实含义、触发时机和边界条件，而非仅靠数值做简单判断。
readyState=1：连接已建立，但尚未发送请求
该状态表示调用 xhr.open() 后、xhr.send() 前，或调用 send() 后浏览器刚完成请求初始化（如设置 headers、解析 URL），但数据还未真正发出到网络层。注意：此时 status 和 statusText 仍不可用，response 相关属性为空。常见误判是把此状态当作“已发包”，实际可能卡在 DNS 解析或 TCP 握手前。
- 适合在此阶段做「请求预埋日志」：记录请求 URL、method、起始时间戳
- 可配合
timeout属性设防：若长时间停留 1 状态，大概率是网络不可达或跨域预检失败 - 不要在此阶段尝试读取
getResponseHeader或responseText，会报错或返回空
readyState=2：响应头已接收，请求完成
此时浏览器已收到 HTTP 响应的第一行（状态行）和所有响应头，但响应体（body）尚未开始接收。status、statusText、getResponseHeader() 都已可用，是校验服务端是否正常响应的关键节点。例如 status === 401 可在此刻捕获并触发登录跳转，无需等整个 body 下载完。
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 推荐在此状态做「响应元信息快照」：记录 status、content-type、x-request-id 等 header
- 若 status 异常（如 503、404），可提前终止监听，避免无意义等待 body
- 注意：部分代理或 CDN 可能延迟发送 header，导致 2 状态持续较久，需结合 timeout 控制
readyState=3：响应体正在流式接收中
从第一个字节响应体到达开始，直到最后一个字节接收完毕前，都处于此状态。对大文件或长轮询，这个状态可能持续数秒甚至更久。responseText（文本）或 response（ArrayBuffer 等）会随数据到达动态更新，但内容可能不完整——尤其当 responseType 为 "text" 时，中文字符易被截断成乱码。
- 仅当明确需要流式处理（如进度条、实时日志渲染）时才依赖此状态
- 读取
responseText前务必检查response.length > 0，避免空字符串误判 - 若
responseType === "json"，切勿在此状态解析response，JSON 解析必须等待 4 状态
readyState=4：请求彻底结束，无论成功或失败
这是最终态：响应体全部接收完毕，连接关闭（HTTP/1.1）或复用完成（HTTP/2）。此时 status、response、responseText 等全部就绪。但注意：readyState === 4 不代表请求成功——status 为 0（如跨域被拒、网络中断）或 4xx/5xx 仍属失败。
- 必须同时校验
status >= 200 && status 才能判定业务成功 -
status === 0通常意味着请求未发出（如 CORS 拦截、HTTPS 页面加载 HTTP 资源） - 建议将「最终结果归因」逻辑放在此状态：区分超时、网络错误、服务端异常、业务错误
状态机不是线性流水线，而是带分支与兜底的响应模型。真实场景中，需结合 onerror、ontimeout、onabort 等事件补全异常路径，并用 XMLHttpRequest.UNSENT（0）作为初始态锚点。监控粒度越细，越容易定位卡点；但过度依赖中间态可能增加兼容性风险——尤其在低版本 IE 中 3 状态行为不稳定。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
