我理解 ，因为同步调用阻止 UI 呈现。
一般给出的另一个原因是内存泄漏问题与 同步 AJAX。
注 ︰ 你不应该使用同步的 XMLHttpRequests，因为由于天生就是异步网络性质的有各种方式记忆和事件可以泄漏时使用同步请求。唯一的例外是同步请求工作井内工人。
如何同步调用可能会导致内存泄漏？
我在寻找一个实际的例子。
任何指向任何关于这一主题的文献就再好不过了。
显示/隐藏原文
I understand
general advice given against the use of synchronous ajax calls, because the synchronous calls block the UI rendering.
The other reason generally given is memory leak isssues with synchronous AJAX.
Note: You shouldn't use synchronous XMLHttpRequests because, due to
the inherently asynchronous nature of networking, there are various
ways memory and events can leak when using synchronous requests. The
only exception is that synchronous requests work well inside Workers.
How synchronous calls could cause memory leaks?
I am looking for a practical example.
Any pointers to any literature on this topic would be great.
如果 XHR 实现正确 ，那么它将不漏 ︰
XMLHttpRequest 对象不能垃圾收集如果其状态打开和设置了 send （） 标志，其状态是 HEADERS_RECEIVED，或其状态正在加载，以下条件之一 ︰ 它具有一个或多个事件侦听器注册其类型是 readystatechange、 进度、 中止、 错误、 负载、 超时或 loadend.
上传完整标志被设置和相关联的 XMLHttpRequestUpload 对象有一个或更多的事件侦听器注册其类型是进步、 中止、 错误、 负载、 超时或 loadend.
XMLHttpRequest 对象被垃圾收集其连接仍处于打开状态，用户代理必须取消提取算法打开此对象的任何实例时，如果丢弃任何任务排队等待他们，并丢弃任何进一步的数据从网络接收他们。
所以你打 .send()后 XHR 对象 （和任何它引用） 成为免疫对 GC。然而， 和它服从 GC 再次成为。它不会在所有不要紧 XHR 对象是同步或异步。在长时间的同步的情况下再次请求没关系因为你会只是被困在发送语句直到服务器响应。
然而，根据对
此幻灯片 它不正确实施至少在铬/铬在 2012 年。规格，将不需要调用 .abort()，因为完成状态意味着 XHR 对象已经应该通常是 GCd。
我找不到甚至一丁点的证据来备份 MDN 声明和我有联系作者通过 twitter。
显示/隐藏原文
If XHR is implemented correctly , then it will not leak:
An XMLHttpRequest object must not be garbage collected if its state is
OPENED and the send() flag is set, its state is HEADERS_RECEIVED, or
its state is LOADING, and one of the following is true:
It has one or more event listeners registered whose type is
readystatechange, progress, abort, error, load, timeout, or loadend.
The upload complete flag is unset and the associated
XMLHttpRequestUpload object has one or more event listeners registered
whose type is progress, abort, error, load, timeout, or loadend.
If an XMLHttpRequest object is garbage collected while its connection
is still open, the user agent must cancel any instance of the fetch
algorithm opened by this object, discarding any tasks queued for them,
and discarding any further data received from the network for them.
So after you hit .send() the XHR object (and anything it references) becomes immune to GC. However,
and it becomes subject to GC again. It wouldn't matter at all if the XHR object is sync or async. In case of a long sync request again it doesn't matter because you would just be stuck on the send statement until the server responds.
However, according to
it was not implemented correctly at least in Chrome/Chromium in 2012. Per spec, there would be no need to call .abort() since the DONE state means that the XHR object should already be normally GCd.
I cannot find even slightest evidence to back up the MDN statement and I have contacted the author through twitter.
我认为该内存泄漏的发生主要是因为垃圾回收器不能胜任其工作。即你对某事的引用和 GC 不能删除它。我写了一个简单的例子 ︰ var getDataSync = function(url) {
console.log("getDataSync");
var request = new XMLHttpRequest();
request.open('GET', url, false);
// `false` makes the request synchronous
request.send(null);
if(request.status === 200) {
return request.responseT
return "";
} catch(e) {
console.log("!ERROR");
var getDataAsync = function(url, callback) {
console.log("getDataAsync");
var xhr = new XMLHttpRequest();
xhr.open("GET", url, true);
xhr.onload = function (e) {
if (xhr.readyState === 4) {
if (xhr.status === 200) {
callback(xhr.responseText);
callback("");
xhr.onerror = function (e) {
callback("");
xhr.send(null);
var requestsMade = 0
var requests = 1;
var url = "http://missing-url";
for(var i=0; i& i++, requestsMade++) {
getDataSync(url);
// getDataAsync(url);
除了同步功能块的大量的东西事实上是另一个大的区别。错误处理。如果你使用 getDataSync 和移除的 try-catch 块并刷新页面，您将看到则会引发错误。这是因为 url 不存在，但现在的问题是垃圾回收器如何工作时则会引发错误。是它清除与该错误相关的所有对象，是它让错误的对象或东西那样。我会很高兴的如果有人知道更多关于这，写在这里。
显示/隐藏原文
I think that memory leaks are happening mainly because the garbage collector can't do its job. I.e. you have a reference to something and the GC can not delete it. I wrote a simple example:
var getDataSync = function(url) {
console.log("getDataSync");
var request = new XMLHttpRequest();
request.open('GET', url, false);
// `false` makes the request synchronous
request.send(null);
if(request.status === 200) {
return request.responseT
return "";
} catch(e) {
console.log("!ERROR");
var getDataAsync = function(url, callback) {
console.log("getDataAsync");
var xhr = new XMLHttpRequest();
xhr.open("GET", url, true);
xhr.onload = function (e) {
if (xhr.readyState === 4) {
if (xhr.status === 200) {
callback(xhr.responseText);
callback("");
xhr.onerror = function (e) {
callback("");
xhr.send(null);
var requestsMade = 0
var requests = 1;
var url = "http://missing-url";
for(var i=0; i& i++, requestsMade++) {
getDataSync(url);
// getDataAsync(url);
Except the fact that the synchronous function blocks a lot of stuff there is another big difference. The error handling. If you use getDataSync and remove the try-catch block and refresh the page you will see that an error is thrown. That's because the url doesn't exist, but the question now is how garbage collector works when an error is thrown. Is it clears all the objects connected with the error, is it keeps the error object or something like that. I'll be glad if someone knows more about that and write here.
同步 XHR 块线程执行，这从 GC 线程函数执行堆栈中的所有对象。
function (b) {
var a = &big data&;
&work with& a and b
变量和 b 此处堵住了 （和整个堆栈太）。
所以，如果 GC 开始工作然后同步 XHR 已阻止堆栈，堆栈的所有变量将被标记为"存活 GC"和从早期堆移动到更持久。语气不应该生存甚至单一 GC 的对象将居住多个垃圾收集和甚至从这些对象的引用将生存 GC。
关于索赔堆栈阻止 GC，和该对象标记为长住的对象 ︰ 请参阅一节
保守垃圾收集。
"标记"对象收费 后 通常堆收费，而且 通常只当 有仍然需要释放更多内存 （如收集标记和席卷对象结构体需要更多时间）。
更新 ︰ 是它真正的泄漏，不只是早期堆无效解决方案吗？
有几件事情要考虑。
多久这些对象将被锁定，请求完毕后？
同步 XHR 可以阻止堆栈为一个无限长的时间，XHR 有没有超时属性 （在所有非 IE 浏览器），网络问题并不罕见。
多少 UI 元素处于锁定状态？如果它阻止记忆只是 1 秒的 20 M = = 200 k 铅在 2 分钟考虑许多背景选项卡。
考虑案件时单个同步块的语气资源和浏览器去交换文件
当另一个事件试图改变 DOM 中的可能被阻止同步 XHR，另一个线程被阻塞 （和它整个的堆栈也）
如果用户将重复导致同步 XHR，整个 浏览器窗口的操作将被锁定。浏览器使用 max = 2 的线程来处理窗口事件。
即使无阻塞这会消耗很多的操作系统和浏览器的内部资源 ︰ 线程、 临界区资源、 用户界面资源、 DOM......想象一下，你可以打开 （由于内存问题） 10 个标签页使用的网站同步 XHR 和 100 与站点选项卡，使用异步 XHR。不是这种内存泄漏。
显示/隐藏原文
Sync XHR block thread execution and all objects in function execution stack of this thread from GC.
function (b) {
var a = &big data&;
&work with& a and b
Variables a and b are blocked here (and whole stack too).
So, if GC started working then sync XHR has blocked stack, all stack variables will be marked as "survived GC" and be moved from early heap to the more persistent. And a tone of objects that should not survive even the single GC will live many Garbage Collections and even references from these object will survive GC.
About claims stack blocks GC, and that object marked as long-live objects: see section Conservative Garbage Collection in
Also, "marked" objects GCed after the usual heap is GCed, and usually only if there is still need to free more memory (as collecting marked-and-sweeped objs takes more time).
Is it really a leak, not just early-heap ineffective solution?
There are several things to consider.
How long these object will be locked after request is finished?
Sync XHR can block stack for a unlimited amount of time, XHR has no timeout property (in all non-IE browsers), network problems are not rare.
How much UI elements are locked? If it block 20M of memory for just 1 sec == 200k lead in a 2min. Consider many background tabs.
Consider case when single sync blocks tone of resources and browser
goes to swap file
When another event tries to alter DOM in may be blocked by sync XHR, another thread is blocked (and whole it's stack too)
If user will repeat the actions that lead to the sync XHR, the whole browser window will be locked. Browsers uses max=2 thread to handle window events.
Even without blocking this consumes lots of OS and browser internal resources: thread, critical section resources, UI resources, DOM ... Imagine that your can open (due to memory problem) 10 tabs with sites that use sync XHR and 100 tabs with sites that use async XHR. Is not this memory leak.
如果同步调用中断 （即通过重新使用客户端对象的用户事件） 之前完成，然后垂悬，无法进行垃圾回收，就可以离开优秀的网络查询.
这是因为，如果发出请求的对象不存在时，请求返回，返回不能完成，但 （如果浏览器是不完美的） 保留在内存中。你很容易可以导致此使用比如删除请求对象，取得了该请求后，但在返回之前。
记得大的问题在 IE 中，回来在 2009 年，但我希望现代浏览器都不受其影响。当然，现代图书馆 (即 JQuery) 防止的情况中，它可能会出现，允许请求作出而不必去想它。
显示/隐藏原文
If the synchronous call is interrupted (i.e. by a user event re-using the XMLHttpRequest object) before it completes, then the outstanding network query can be left hanging, unable to be garbage collected.
This is because, if the object that initiated the request does not exist when the request returns, the return cannot complete, but (if the browser is imperfect) remains in memory. You can easily cause this using setTimeout to delete the request object after the request has been made but before it returns.
I remember I had a big problem with this in IE, back around 2009, but I would hope that modern browsers are not susceptible to it. Certainly, modern libraries (i.e. JQuery) prevent the situations in which it might occur, allowing requests to be made without having to think about it.
使用的等速 AJAX 请求通常会引起内存泄漏 ︰ 使用 setInterval/setTimout 造成循环调用。
客户端代码-当在引用被移除，所以 xhr 变得不可访问
发生内存泄漏的浏览器因为一些原因不释放内存中对象的不需要任何更多的时候。
这可能是因为浏览器 bug，浏览器的扩展问题，更很少，我们的代码体系结构中的错误。
这里是当事业在新的上下文中运行 setInterval 的内存泄漏示例 ︰
= process.binding('evals').Context,
= process.binding('evals').Script,
process.nextTick(function memory() {
var mem = process.memoryUsage();
console.log('rss:', Math.round(((mem.rss/)) + "MB");
setTimeout(memory, 100);
console.log("STARTING");
process.nextTick(function run() {
var context = new Context();
context.setInterval = setI
Script.runInContext('setInterval(function() {}, 0);',
context, 'test.js');
if (total) {
process.nextTick(run);
console.log("COMPLETE");
显示/隐藏原文
Memory leaks using syncronous AJAX requests are often caused by:
using setInterval/setTimout causing circular calls.
XmlHttpRequest - when the reference is removed, so xhr becomes inaccessible
Memory leak happens when the browser for some reason doesn’t release memory from objects which are not needed any more.
This may happen because of browser bugs, browser extensions problems and, much more rarely, our mistakes in the code architecture.
Here's an example of a memory leak being cause when running setInterval in a new context:
= process.binding('evals').Context,
= process.binding('evals').Script,
process.nextTick(function memory() {
var mem = process.memoryUsage();
console.log('rss:', Math.round(((mem.rss/)) + "MB");
setTimeout(memory, 100);
console.log("STARTING");
process.nextTick(function run() {
var context = new Context();
context.setInterval = setI
Script.runInContext('setInterval(function() {}, 0);',
context, 'test.js');
if (total) {
process.nextTick(run);
console.log("COMPLETE");
友情链接：Ajax - nycqwert的专栏 - CSDN博客
AJAX(Asynchronous& Javascript and XML)---异步交互(通信)
1）& 使用XHTML和CSS标准的现实技术
2）& 使用DOM进行动态现实和交互
3）& XML和XSLT进行数据交换和处理
4）& XMLHttpRequest进行数据的检索----浏览器内置的对象
5）& Javascript来讲以上技术融合；
2、& 异步通信工作原理
同步：用户（在URL地址栏输入页面请求）---服务器端接受请求进行相应处理（这段时间客户处于等待状态，后续操作被暂停）----返回数据到客户端—客户才能继续操作
异步：用户（在URL地址栏输入页面请求）--服务器接收信息（函数或者新方法等待接收信息）--客户端继续向下执行------（如果服务器处理请求结束，结果返回到新方法）------浏览器只处理所需的数据（不涉及整个页面的刷新）
1）& 改表单验证方式，不需要打开新的页面，也不需要进行整个页面的提交；
2）& 不需要刷新，减少了客户的等待时间；
3）& 按需要获取数据信息
4）& 读取外部的数据，进行信息整合；
5）& 异步交互
4、& 登陆的案例
1）& 服务器端文件demo.php
功能：验证用户名称的合法性
2）& 前台页面index.html
功能：显示输入用户名的区域
jquery 是一个Javascript库，简化编程过程
&&&&& ajax的一个框架：
使用：&script type=”text/javascript” src=”文件”&&/scrpt&
& Get:将信息通过URL地址栏进行传递
& Post：将信息通过HTTP方式进行传递
&一个表单包含所有信息（用户、口令、身份证等）
Submit作用：针对表单对象，点击后执行---将表单区域包含
所有数据通过method属性指定的方式发送到action熟悉ing指定
Get：把表单里所有（input、select、textarea等）数据当做参数
&& 通过URL地址栏传递
& =””....
Post:把数据通过HTTP传递
名字：值
Firebug:调试功能
& Step over:单步执行（进入）按照语句的顺序执行，当碰到方法，不进入方法内部
Step into：单步执行（跳过）按照语句的顺序执行，当碰到方法，进入方法体内部
Step out：跳出& 结束执行
浏览器的缓存
变化的时间戳
两次输入的请求相同，浏览器不会每次都到服务器端获取页面信息
避免缓存采取方法：在URL后增加
XMLHttpRequest
新的浏览器具备组建XMLHttpRequest
IE7、IE8、firefox、mozillar、opera
旧的浏览器控件ActiveXObject
&& 开放的集合（提供了实现各种功能的方法，flash、动态效果）
旧的浏览器控件ActiveXObject
& 开放的集合（提供了实现各种功能的方法，flash、动态效果）
IE6、IE5.5、IE5等
Php操作xml
Php内置DOMDocument
&$_doc=new DOMDocument()//
AJAX推送与拉取方式的比较
11:24作者：张凯峰出处：IT专家网责任编辑：方舟
　　使用Ajax可以开发出基于浏览器的具有高用户交互性和几乎不易觉察到延迟的web应用。实时的动态数据比如新闻标题、证券报价和拍卖行情都需要尽快地发送给用户。然而，AJAX仍然受限于web请求/响应架构的弱点，使得服务器不能推送实时动态的web数据。
　　Delft科技大学的Engin Bozdag、Ali Mesbah和Arie van Deursen一起讨论了下面这些可以实现基于web的实时事件通知的方法：
　　1.HTTP拉取方式：在这种传统的方法中，客户端以用户可定义的时间间隔去检查服务器上的最新数据。这种拉取方式的频率要足够高才能保证很高的数据精确度，但高频率可能会导致多余的检查，从而导致较高的网络流量。而另一方面，低频率则会导致错过更新的数据。理想地，拉取的时间间隔应该等于服务器状态改变的速度。
　　2.HTTP流：这种方法由存在于不间断的HTTP连接响应中或某个XMLHttpRequest连接中的服务器数据流所组成。
　　3.反转AJAX：服务流应用到AJAX，就是所谓的反转AJAX 或者COMET 。它使得服务器在某事件发生时可以发送消息给客户端，而不需要客户端显式的请求。目标在于达到状态变化的实时更新。COMET使用了HTTP/1.1中的持续连接的特性。通过HTTP/1.1，除非另作说明，服务器和浏览器之间的TCP连接会一直保持连接状态，直到其中一方发送了一条明显的“关闭连接”的消息，或者有超时以及网络错误发生。
　　4.长时间轮询：也就是所谓的异步轮询，这种方式是纯服务器端推送方式和客户端拉取方式的混合。它是基于BAYEUX协议的。这个协议遵循基于主题的发布——订阅机制。在订阅了某个频道后，客户端和服务器间的连接会保持打开状态，并保持一段事先定义好的时间。如果服务器端没有事件发生，而发生了超时，服务器端就会请求客户端进行异步重新连接。如果有事件发生，服务器端会发送数据到客户端，然后客户端重新连接。
在他们的实验性研究中，作者们在一个利用COMET推送方式实现(Dojo的Cometd库)的AJAX应用和一个纯拉取方式的应用之间，对数据一致性、服务器性能、网络性能以及数据遗失进行了比较。
解开AJAX技术生命中的达芬奇密码
10:13作者：蒋涛出处：CSDNBLOG责任编辑：方舟
　　几乎每位在开发JavaScript时尝试应用面向对象技术的开发者，或多或少都会问自己一个问题：“如何调用父类（super class）的方法？”在Ajax技术还没有目前这样炙手可热之前，这种问题很少出现，因为大多数开发者仅在进行客户端form验证或者简单的DHTML/DOM操作时使用JavaScript。在那些简单的解决方案中，函数式编程（functional programming）是很有意义的，面向对象编程则处在次之重要的位置。现在，Ajax技术发展势头迅猛，开发者已经建立了一个调用大量客户端JavaScript、不断增长的、复杂的系统。因此，在JavaScript上尝试OO技术便成为了管理复杂性的一种手段。在此过程中，多数开发者很快便认识到：JavaScript是一种原型化的（prototypical）语言，它缺少OO自身带来的多种便利。
　　OO设计的主旨和关于它的一些话题谈起来很大，但只着眼于Class的定义方式，我认为它是JavaScript开发者尝试解决问题的首选。因此，你可以在互联网上找到许多不同的问题解决案例，但在我看过它们后不免有些失望——这些案例都是在某个场合下适用，而不是放之四海而皆准的通法。而我对这个话题的兴趣来自于我的team在开发 ThinWire Ajax Framework 的影响。由于这个框架生成出对客户端代码的需求，才使我们“被迫”去实现可靠的、支持父类方法调用的OO模式。通过父类调用，你可以进一步依靠类的继承特性来核心化通用代码，从而更易于减少重复代码，去掉客户端代码的坏味道。
　　下面罗列出了一些在我的研究过程中遇到的解决方式。最终，我没有从中找出一个可以接收的解决方案，于是我不得不实现一个自己的解决方案，你将在本文的结尾部分看到这个方案。
　　然而父类调用在这里是最重要的OO机制，因此我需要一个相应的工作模式，也正是因为在我的观点中原型化方式是丑陋的，所以我更需要一种更加自然地使用JavaScript定义类的方法。
　　More Solutions：
　　好吧，让我们进入讨论。正如开发者所察觉的那样，在JS中实现基本的继承是很容易的事，事实上有一些众所周知的方法：
　　丑陋的Solution：
　　没有进行父类调用的简单继承:
// 提前写好的JavaScript Class定义和继承
// 当然，这种代码很丑陋，散发着代码的坏味道。
function BaseClass() {
&&& //BaseClass constructor code goes here
BaseClass.prototype.getName = function() {
&&& return &BaseClass&;
function SubClass() {
&&& //SubClass constructor code goes here
//Inherit the methods of BaseClass
SubClass.prototype = new BaseClass();
//Override the parent's getName method
SubClass.prototype.getName = function() {
&&& return &SubClass&;
//Alerts &SubClass&
alert(new SubClass().getName());
　　导致 IE内存泄露 的Solution：
　　这种实现方式能够导致在IE中的内存泄漏，你应该尽量避免：
// 运行时的JavaScript Class 定义和继承
// 看上去很传统，但这些脚本会导致在Internet Explorer中的内存泄漏.
function BaseClass() {
&&& this.getName = function() {
&&&&&&& return &BaseClass&;
&&& //BaseClass constructor code goes here
function SubClass() {
&&& //在对象实例建立时重载父类的getName方法
&&& this.getName = function() {
&&&&&&& return &SubClass&;
&&& //SubClass constructor code goes here
//Inherit the methods of BaseClass
SubClass.prototype = new BaseClass();
//Alerts &SubClass&
alert(new SubClass().getName());
　　就像我在第一个实现方法中所注释的那样，第一个实现方法有些丑陋，但它相比引起内存泄漏的第二种方式便是首选了。
　　我把这两种方法放在这里的目的是指出你不应该使用它们。
全面剖析XMLHttpRequest对象
09:31作者：朱先忠编译出处：天极软件责任编辑：方舟
　　　　　　　
　　　　　　　　推荐：AJAX专区　
　　XMLHttpRequest对象是当今所有AJAX和Web 2.0应用程序的技术基础。尽管软件经销商和开源社团现在都在提供各种AJAX框架以进一步简化XMLHttpRequest对象的使用；但是，我们仍然很有必要理解这个对象的详细工作机制。
　　一、 引言
　　异步JavaScript与XML(AJAX)是一个专用术语，用于实现在客户端脚本与服务器之间的数据交互过程。这一技术的优点在于，它向开发者提供了一种从Web服务器检索数据而不必把用户当前正在观察的页面回馈给服务器。与现代浏览器的通过存取浏览器DOM结构的编程代码(JavaScript)动态地改变被显示内容的支持相配合，AJAX让开发者在浏览器端更新被显示的HTML内容而不必刷新页面。换句话说，AJAX可以使基于浏览器的应用程序更具交互性而且更类似传统型桌面应用程序。
　　Google的Gmail和Outlook Express就是两个使用AJAX技术的我们所熟悉的例子。而且，AJAX可以用于任何客户端脚本语言中，这包括JavaScript，Jscript和VBScript。
　　AJAX利用一个构建到所有现代浏览器内部的对象-XMLHttpRequest-来实现发送和接收HTTP请求与响应信息。一个经由XMLHttpRequest对象发送的HTTP请求并不要求页面中拥有或回寄一个＜form＞元素。AJAX中的&A&代表了&异步&，这意味着XMLHttpRequest对象的send()方法可以立即返回，从而让Web页面上的其它HTML/JavaScript继续其浏览器端处理而由服务器处理HTTP请求并发送响应。尽管缺省情况下请求是异步进行的，但是，你可以选择发送同步请求，这将会暂停其它Web页面的处理，直到该页面接收到服务器的响应为止。
　　微软在其Internet Explorer(IE) 5中作为一个ActiveX对象形式引入了XMLHttpRequest对象。其他的认识到这一对象重要性的浏览器制造商也都纷纷在他们的浏览器内实现了XMLHttpRequest对象，但是作为一个本地JavaScript对象而不是作为一个ActiveX对象实现。而如今，在认识到实现这一类型的价值及安全性特征之后，微软已经在其IE 7中把XMLHttpRequest实现为一个窗口对象属性。幸运的是，尽管其实现(因而也影响到调用方式)细节不同，但是，所有的浏览器实现都具有类似的功能，并且实质上是相同方法。目前，W3C组织正在努力进行XMLHttpRequest对象的标准化，并且已经发行了有关该W3C规范的一个草案。
　　本文将对XMLHttpRequest对象API进行详细讨论，并将解释其所有的属性和方法。
　　二、 XMLHttpRequest对象的属性和事件
　　XMLHttpRequest对象暴露各种属性、方法和事件以便于脚本处理和控制HTTP请求与响应。下面，我们将对此展开详细的讨论。
readyState属性
　　当XMLHttpRequest对象把一个HTTP请求发送到服务器时将经历若干种状态：一直等待直到请求被处理；然后，它才接收一个响应。这样以来，脚本才正确响应各种状态-XMLHttpRequest对象暴露一个描述对象的当前状态的readyState属性，如表格1所示。
　　表格1.XMLHttpRequest对象的ReadyState属性值列表。
ReadyState取值&&&& 描述
0 &&& 描述一种&未初始化&状态；此时，已经创建一个XMLHttpRequest对象，但是还没有初始化。
1 &&& 描述一种&发送&状态；此时，代码已经调用了XMLHttpRequest open()方法并且XMLHttpRequest已经准备好把一个请求发送到服务器。
2 &&& 描述一种&发送&状态；此时，已经通过send()方法把一个请求发送到服务器端，但是还没有收到一个响应。
3 &&& 描述一种&正在接收&状态；此时，已经接收到HTTP响应头部信息，但是消息体部分还没有完全接收结束。
4 &&& 描述一种&已加载&状态；此时，响应已经被完全接收。
　　onreadystatechange事件
　　无论readyState值何时发生改变，XMLHttpRequest对象都会激发一个readystatechange事件。其中，onreadystatechange属性接收一个EventListener值-向该方法指示无论readyState值何时发生改变，该对象都将激活。
　　responseText属性
　　这个responseText属性包含客户端接收到的HTTP响应的文本内容。当readyState值为0、1或2时，responseText包含一个空字符串。当readyState值为3(正在接收)时，响应中包含客户端还未完成的响应信息。当readyState为4(已加载)时，该responseText包含完整的响应信息。
　　responseXML属性
　　此responseXML属性用于当接收到完整的HTTP响应时(readyState为4)描述XML响应；此时，Content-Type头部指定MIME(媒体)类型为text/xml，application/xml或以+xml结尾。如果Content-Type头部并不包含这些媒体类型之一，那么responseXML的值为null。无论何时，只要readyState值不为4，那么该responseXML的值也为null。
　　其实，这个responseXML属性值是一个文档接口类型的对象，用来描述被分析的文档。如果文档不能被分析(例如，如果文档不是良构的或不支持文档相应的字符编码)，那么responseXML的值将为null。
　　status属性
　　这个status属性描述了HTTP状态代码，而且其类型为short。而且，仅当readyState值为3(正在接收中)或4(已加载)时，这个status属性才可用。当readyState的值小于3时试图存取status的值将引发一个异常。
　　statusText属性
　　这个statusText属性描述了HTTP状态代码文本；并且仅当readyState值为3或4才可用。当readyState为其它值时试图存取statusText属性将引发一个异常。
我的热门文章
即使是一小步也想与你分享