jQuery 1.5 Deferred机制解析：从状态机到Promise雏形

1. 项目概述：一次穿越十年的技术考古——重读 Gray Zhang 的 jQuery 1.5 beta1 笔记

你有没有试过翻出自己五年前写的代码注释？那种混合着技术兴奋、认知局限和一点小得意的语气，像一封写给未来自己的信。而 Gray Zhang 这篇《Novice Doodle from Gray Zhang》，就是一封写给整个前端社区的、带着体温的技术手札。它不是一份冷冰冰的 Release Notes，而是一个真实开发者在 jQuery 1.5 beta1 刚发布时，一边啃源码一边敲下的即时战报。标题里的“Novice Doodle”（新手涂鸦）是谦辞，但字里行间全是老手才有的精准切口——他没去复述文档里能查到的 API 变更，而是直扑心脏：jQuery._Deferred是什么？为什么ready函数要被“嫁接”过去？cloneFixAttribute那几十行代码，到底在跟 IE 的哪个幽灵搏斗？这些今天看起来理所当然的设计，在当时就是一道道需要亲手凿开的岩壁。

这篇笔记的核心关键词，其实是“可扩展性”与“状态机”。jQuery 1.5 的 AJAX 重写之所以成为分水岭，并非因为它更快或更炫，而是它第一次把异步操作的生命周期，从一堆零散的回调函数，抽象成一个可观察、可组合、可继承的状态容器。_Deferred就是这个容器的原始胚体，它用最朴素的“队列+开关”模型，实现了现代 Promise 的雏形。而jQuery.Deferred则在此基础上，叠加了“成功/失败”双通道，为后续的链式调用（.then()）和错误隔离埋下了伏笔。这背后是一次深刻的范式迁移：从前端工程师写代码的角度看，我们不再是在“处理一个请求”，而是在“订阅一个状态流”。这种思维转变，比任何语法糖都重要。它直接影响了后来的 Q、When.js，乃至原生 Promise 和 async/await 的设计逻辑。所以，重读这篇笔记，不是为了怀旧，而是为了看清那条从“回调地狱”通往“声明式编程”的隐秘小径是如何被一砖一瓦铺就的。无论你现在用的是 React Query、SWR 还是 Vue 的useAsync，其底层的契约精神，都能在这份十年前的“涂鸦”里找到最初的草图。

2. 核心机制解构：_Deferred与Deferred的双生架构

2.1_Deferred：一个极简状态机的诞生

jQuery._Deferred是 jQuery 1.5 中所有异步能力的基石，它的设计哲学可以用四个字概括：够用就好。它没有试图解决所有异步问题，而是聚焦于一个最核心的场景：如何可靠地管理一组函数的执行时机与状态。理解它，必须抛开“Promise”这个后见之明的标签，回到它诞生的语境——一个需要让$(document).ready()在 DOM 加载完成时，精确、无遗漏地触发所有注册函数的时刻。

它的内部结构异常简单，本质上就是一个带状态标记的对象：

// 简化示意，非真实源码 function _Deferred() { this._fns = []; // 存储待执行的函数队列 this._isResolved = false; // 状态开关：false=未触发，true=已触发 }

这个看似单薄的结构，却通过三个关键接口，构建出了完整的控制流：

• done(fn)：这是它的“注册入口”。当_isResolved为false时，fn被推入_fns队列；一旦_isResolved变为true，fn会立刻被执行。这个“延迟注册，即时执行”的特性，正是ready函数能无缝切换的基础。想象一下，如果页面加载极快，你的$(document).ready(...)代码在 DOMContentLoaded 事件触发之后才执行，传统数组方案会直接丢失这个回调，而_Deferred会立刻把它执行掉，保证了语义的一致性。

• fire(context, args)：这是它的“状态引爆点”。它遍历_fns中的所有函数，以context为this，args为参数逐一调用。最关键的是，fire执行完毕后，会将_isResolved设为true。这个动作不可逆，它标志着状态机从“等待”进入了“已触发”态。此后，所有对done()的调用，都会跳过队列，直接执行函数。这就像一个闸门，fire是打开它的钥匙，一旦开启，水流（函数执行）便无法阻挡。

• resolve()：这是fire()的一个便捷别名，等价于fire(this, arguments)。它省去了手动传参的麻烦，让使用者可以更专注地表达“我现在要触发这个事件了”的意图。

提示：_Deferred的精妙之处在于，它用最少的代码，解决了“注册时机不确定”和“执行时机确定”之间的矛盾。它不关心fire是由谁、在何时调用的，只负责确保所有在fire前后注册的函数，都能在fire发生的那一刻或之后，被正确地、按序地执行。这种“状态驱动”的思想，是它超越readyList数组的根本原因。

2.2jQuery.Deferred：双通道状态机的进化

如果说_Deferred是一个单向的“信号发射器”，那么jQuery.Deferred就是一个双向的“通信协议栈”。它并非对_Deferred的简单封装，而是基于其内核，构建了一个更复杂的、具备“成功”与“失败”两种独立状态的系统。它的实现思路非常直观：用两个_Deferred实例，分别管理成功路径和失败路径。

// 简化示意 function Deferred() { this._deferred = new _Deferred(); // 管理“成功”回调 this._failDeferred = new _Deferred(); // 管理“失败”回调 }

这个双实例模型，直接催生了新的接口语义：

• then(doneFn, failFn)：这是Deferred最具革命性的接口。它将doneFn注册到_deferred，将failFn注册到_failDeferred。这意味着，一个Deferred对象现在可以同时监听两种截然不同的结果。这为 AJAX 请求的处理提供了完美的抽象：.then(successHandler, errorHandler)比.success().error()更加清晰、更具组合性。

• resolve()与reject()：它们不再是简单的fire，而是分别作用于_deferred和_failDeferred。resolve()触发成功通道，reject()触发失败通道。两者互不影响，一个请求的成功与否，不会干扰另一个通道的注册函数。

• isResolved()与isRejected()：它们分别代理了_deferred.isResolved()和_failDeferred.isResolved()。这使得外部代码可以精确地查询当前Deferred对象所处的复合状态。

注意：jQuery.Deferred移除了_Deferred的cancel()方法。这是一个深思熟虑的设计取舍。cancel()的存在意味着状态可以被“撤销”，这在复杂的异步流程中会引入巨大的不确定性。Deferred选择拥抱“状态不可逆”的原则，即一旦resolve()或reject()被调用，该Deferred的生命周期就进入了终局。这极大地简化了状态管理的复杂度，也为后续的链式调用（如.pipe()，即后来的.then()）奠定了坚实基础。一个可取消的 Promise，在工程实践中往往弊大于利。

2.3 从ready到Deferred：一次优雅的“嫁接”

jQuery.ready的重构，是Deferred机制价值最直观的体现。在 jQuery 1.4.4 中，ready的实现依赖于一个全局数组readyList：

// jQuery 1.4.4 伪代码 var readyList = []; function DOMContentLoaded() { for (var i = 0; i < readyList.length; i++) { readyList[i].call(document, jQuery); } }

这个方案的问题在于，它是一个纯粹的“广播”模型。一旦DOMContentLoaded事件触发，所有注册的函数就被一股脑地执行，没有任何状态反馈，也无法进行二次注册。

而在 1.5 中，readyList被替换为一个jQuery._Deferred实例：

// jQuery 1.5 伪代码 var readyList = jQuery._Deferred(); function DOMContentLoaded() { readyList.fire(document, [jQuery]); }

这个变化带来的好处是质的飞跃：

1. 注册无惧时机：无论你的$(document).ready(...)是在 DOM 加载前、加载中还是加载后执行，它都能被正确处理。
2. 状态可观察：你可以通过readyList.isResolved()来判断 DOM 是否已经就绪，这在一些需要动态决策的场景下非常有用。
3. 能力可复用：readyList不再是一个私有变量，它变成了一个公开的、可被其他模块消费的Deferred对象。例如，一个插件可以这样写：readyList.done(function(){ /* 插件初始化 */ });，完全融入了 jQuery 的异步生态。

这种“嫁接”，不是简单的代码搬运，而是一次架构层面的升维。它把一个特定功能（DOM 就绪）的实现，提升为一个通用的、可组合的异步原语。这正是优秀框架设计的标志：让具体问题的解决方案，成为解决更广泛问题的工具。

3. 深度实操解析：cloneFixAttribute与 IE 兼容性战争

3.1 IE 的cloneNode陷阱：一个被遗忘的幽灵

在 jQuery 1.5 的 DOM 操作改进中，cloneFixAttribute函数的引入，堪称一场针对 IE 6-8 的微型特种作战。要理解它的价值，我们必须先直面那个早已被时代掩埋，但在当时却让无数前端工程师夜不能寐的 BUG：IE 的cloneNode(true)会把事件监听器也一并复制。

在标准浏览器中，cloneNode(true)只会克隆节点的结构、属性和文本内容，而不会克隆通过addEventListener或onclick=绑定的事件。这是符合直觉且安全的。但在 IE 6-8 中，cloneNode(true)的行为是“深度克隆”，它会把onclick、onmouseover等内联事件属性，连同其绑定的 JavaScript 字符串，一起复制到新节点上。这导致了一个灾难性的后果：当你克隆一个带有onclick="alert('hello')"的按钮时，新按钮也会拥有完全相同的onclick属性。如果你随后又为新按钮绑定了一个新的onclick事件，那么点击它时，两个alert会依次弹出。更糟的是，如果这些事件监听器引用了闭包中的变量，克隆操作还可能引发难以追踪的内存泄漏。

jQuery 1.4.4 的应对策略是“绕道而行”：放弃使用cloneNode，转而采用innerHTML方案。即，先获取原节点的outerHTML，再用document.createElement创建一个新元素，最后用innerHTML将 HTML 字符串注入。这种方法虽然能规避事件克隆，但它带来了新的问题：innerHTML会破坏节点上的>// 无论在哪个浏览器，代码都一样 var xmlDoc = jQuery.parseXML('<root><child>text</child></root>'); var $xml = jQuery(xmlDoc); var text = $xml.find('child').text(); // "text"

它的内部实现，就是一次经典的“特性检测”：

// 简化示意 function parseXML(data) { if (window.DOMParser) { // 标准浏览器路径 var parser = new DOMParser(); return parser.parseFromString(data, 'text/xml'); } else { // IE 路径 var xmlDoc = new ActiveXObject('Microsoft.XMLDOM'); xmlDoc.async = 'false'; xmlDoc.loadXML(data); return xmlDoc; } }

这个函数的意义，远超一个工具方法。它代表了一种工程哲学：将平台的碎片化，封装在框架的黑盒之中，让应用层的代码得以在统一的、稳定的契约上运行。这种“向下兼容，向上统一”的设计，是 jQuery 能够风靡一时的关键所在。它让开发者可以专注于业务逻辑，而不是浏览器的恩怨情仇。

4. AJAX 重写的全景图：从胶水到引擎的蜕变

4.1jXHR：一个被精心设计的中间层

jQuery 1.5 的 AJAX 重写，其最核心的成果，就是jXHR（jQuery XMLHttpRequest）对象的诞生。在 1.4.4 中，AJAX 的回调函数（如success、error）接收到的参数，是原生的XMLHttpRequest（XHR）对象。这个对象虽然强大，但其 API 在不同浏览器间存在细微差异，且其状态码（status）的含义并不总是直观。例如，IE 的一个著名 BUG：当服务器返回 HTTP 204（No Content）状态时，IE 会错误地将其报告为 1223。这迫使开发者在error回调中写一堆if (xhr.status === 1223) { /* treat as 204 */ }的丑陋逻辑。

jXHR的出现，就是为了终结这一切。它不是一个全新的网络请求引擎，而是一个包裹在原生 XHR 之上的、高度封装的“适配器”和“增强器”。它的主要职责有三：

1. 状态码标准化：jXHR会拦截原生 XHR 的status，并对其进行智能修正。当它检测到status === 1223时，会自动将其映射为204。开发者在回调中看到的，永远是符合 HTTP 规范的、正确的状态码。这消除了一个长期存在的、令人抓狂的兼容性黑洞。

2. API 统一化：jXHR提供了一套精简、一致的接口，如getResponseHeader()、getAllResponseHeaders()、abort()等。它屏蔽了 IE 中getResponseHeader的大小写敏感问题，以及getAllResponseHeaders在某些版本中返回null的怪异行为。开发者只需与jXHR交互，无需关心底层是XMLHttpRequest还是ActiveXObject。

3. 上下文增强：jXHR对象上挂载了大量 jQuery 特有的属性和方法，如responseText、responseXML、statusText，甚至还有jqXHR自身的done()、fail()、always()方法，使其本身就可以作为一个Deferred对象来使用。这为链式调用和 Promise 风格的编程铺平了道路。

提示：jXHR的设计，完美诠释了“面向接口编程”的思想。它没有试图取代 XHR，而是定义了一个更高层次的、更友好的接口契约。这使得 jQuery 的 AJAX 模块在未来可以轻松地被替换成 Fetch API 或其他更现代的网络库，而不会破坏上层应用的代码。这是一种极具前瞻性的架构设计。

4.2statusCode：精细化错误处理的开端

statusCode配置项的引入，是 jQuery AJAX 从“粗放式”走向“精细化”管理的标志性事件。在 1.4.4 中，错误处理主要依靠error回调，它接收一个笼统的“请求失败”信号，开发者需要自己去解析xhr.status和textStatus来判断具体原因。这种方式在面对复杂的后端服务时，显得力不从心。

statusCode提供了一种声明式的、基于 HTTP 状态码的路由机制：

$.ajax({ url: '/api/user', statusCode: { 200: function() { console.log('用户获取成功'); }, 401: function() { window.location.href = '/login'; }, // 未授权，跳转登录 404: function() { alert('用户不存在'); }, 500: function() { alert('服务器内部错误，请稍后再试'); } } });

这个配置项的执行逻辑，是 jQuery 1.5 新增的、一套严谨的回调触发顺序的一部分：

1. 主回调：根据响应状态，首先触发success（2xx, 304）或error（其他）。
2. 状态码回调：紧接着，根据xhr.status，查找并触发statusCode对象中对应的函数。
3. 完成回调：无论成功或失败，都会触发complete。
4. 全局回调：最后，触发ajaxComplete等全局事件。

这种分层、有序的回调体系，让错误处理变得前所未有的清晰和可控。它不再是一个“兜底”的error函数，而是一张覆盖了所有可能 HTTP 状态的、细粒度的响应地图。这对于构建健壮的、用户体验良好的 Web 应用至关重要。

4.3$.get/$.post的合并：DRY 原则的胜利

$.get和$.post在 1.4.4 中是两个几乎完全相同的函数，唯一的区别就是type: 'GET'和type: 'POST'这个配置项。这种重复，违反了软件工程中最基本的 DRY（Don't Repeat Yourself）原则。jQuery 1.5 用一个简洁的$.each循环，一举解决了这个问题：

$.each(['get', 'post'], function(i, method) { $[method] = function(url, data, callback, type) { // 统一的 AJAX 调用逻辑 return $.ajax({ type: method.toUpperCase(), // 'get' -> 'GET' url: url, data: data, success: callback, dataType: type }); }; });

这个改动看似微小，但其意义重大。它表明 jQuery 的核心团队，已经开始将框架的维护性、可读性和可扩展性，置于与功能性同等重要的地位。一个没有重复代码的框架，意味着更少的 Bug、更快的迭代速度，以及更清晰的代码脉络。这为后续的$.ajaxSetup()支持链式调用（return this;）等改进，打下了坚实的基础。

5. 遗留细节与工程实践启示

5.1jQuery.hasData与jQuery.expando：数据管理的双重保险

jQuery.hasData和jQuery.expando的改进，揭示了 jQuery 在数据管理这一底层领域所付出的精微努力。

• jQuery.hasData(element)：这个新增的静态方法，提供了一个安全、高效的途径来判断一个 DOM 元素是否已被 jQuery 关联了数据。在 1.4.4 中，开发者通常需要检查element[jQuery.expando]是否存在，但这是一种脆弱的、依赖于内部实现的 hack。hasData将其封装为一个公开、稳定的 API，体现了框架对“封装性”和“API 稳定性”的重视。

• jQuery.expando的随机化：expando是 jQuery 用来在 DOM 元素上挂载数据的唯一标识符，其默认值是"jQuery" + 时间戳。在 1.5 中，它被增强为"jQuery" + (jQuery.fn.jquery + Math.random()).replace(/\D/g, "")。这个改动的动机，是为了应对一种极其罕见但后果严重的场景：在一个页面中，通过 RequireJS、SeaJS 等模块加载器，意外地加载了多个不同版本的 jQuery。如果它们的expando名称相同（比如都是"jQuery144"），那么后加载的 jQuery 就会覆盖先加载的 jQuery 在元素上存储的数据，导致数据错乱、插件失效。通过加入Math.random()，每个 jQuery 实例的expando都是独一无二的，从而彻底杜绝了这种冲突。这体现了 jQuery 团队对“边缘场景”的极致关注——他们不仅考虑“正常情况”，更在为那些“不应该发生，但万一发生了”的情况，准备好了保险丝。

5.2attr()与hasClass的兼容性补丁：细节决定成败

jQuery 1.5 在 DOM 操作细节上的修补，是其作为工业级框架的又一佐证。

• attr()对AttributeNode的支持：在 1.4.4 中，attr()方法拒绝从TextNode和CommentNode上获取属性，这是合理的，因为它们本就不该有属性。但在 1.5 中，它增加了一个对AttributeNode（nodeType == 2）的支持。AttributeNode是 DOM Level 1 中的一个古老概念，代表一个属性节点本身（如<div id="a">中的id="a"这个节点）。虽然现代开发中极少直接操作AttributeNode，但这个支持，保证了 jQuery 在处理一些特殊 XML 文档或遗留 DOM 结构时的鲁棒性。

• hasClass等方法对\r的支持：hasClass、addClass、removeClass在 1.4.4 中，使用\n和\t来分割className字符串。在 1.5 中，增加了对\r（回车符）的支持。这看似是一个微不足道的字符补丁，但它解决的是 Windows 平台下\r\n换行符的兼容性问题。一个合格的跨平台框架，必须能正确处理所有主流操作系统的文本约定。这个补丁，就是 jQuery 对“Windows 友好”承诺的无声践行。

5.3ajaxSetup的链式调用：API 设计的渐进式演进

ajaxSetup()函数在 1.5 中增加了一行return this;，使其支持链式调用。这个改动，是 jQuery 整体 API 设计哲学的一次自然延伸。jQuery 的核心魅力之一，就是其流畅的链式调用风格（$('#myDiv').css('color', 'red').show().fadeIn();）。ajaxSetup()作为一个全局配置函数，此前是“孤岛式”的，无法融入这个流畅的链条。return this;的加入，让它终于可以和其他 jQuery 方法一样，被自然地串联起来：

$.ajaxSetup({timeout: 5000}) .ajaxSetup({dataType: 'json'}) .ajax({url: '/api/data'}); // 这当然是错的，但说明了链式调用的可能性

虽然在实际开发中，ajaxSetup的链式调用并不常见（因为它是全局配置），但这个改动的意义在于，它保持了 jQuery API 的一致性。它向开发者传递了一个明确的信号：jQuery 的所有公共方法，都遵循同一套设计规范。这种一致性，降低了学习成本，提升了代码的可预测性，是大型开源项目成熟度的重要标志。

6. 常见问题与实战排查技巧

6.1Deferred状态混淆：resolve()与reject()的误用

问题现象：在 AJAX 请求的success回调中，错误地调用了deferred.reject()，导致后续的.then(null, failHandler)被触发，而failHandler中的逻辑（如显示错误提示）被错误地执行。

根本原因：混淆了Deferred对象的“所有权”。一个Deferred对象，其resolve()和reject()方法，应该由创建它的、负责执行异步操作的代码来调用。在 jQuery 的 AJAX 中，$.ajax()内部会创建一个Deferred，并根据请求结果自动调用resolve()或reject()。开发者在success或error回调中，只是“消费者”，不应该再去干预Deferred的状态。

排查与解决：

1. 检查调用栈：在failHandler中打断点，查看调用栈，确认reject()是由谁发起的。
2. 审查回调逻辑：确保success回调中只做数据处理、UI 更新等“副作用”操作，绝不调用deferred.resolve()或deferred.reject()。
3. 正确做法：如果需要在success中触发另一个异步操作，应该返回一个新的Deferred或 Promise，而不是修改当前的Deferred。例如：

// 错误 $.ajax({url: '/api/data'}).done(function(data) { deferred.reject(); // ❌ 绝对不要这样做 }); // 正确：返回一个新的 Promise $.ajax({url: '/api/data'}).done(function(data) { return $.ajax({url: '/api/related-data'}); // ✅ 返回一个新的 Promise，形成链式 });

6.2cloneFixAttribute失效：IE 下事件仍被克隆

问题现象：在 IE 8 下，使用$(element).clone(true)克隆的节点，其onclick事件依然被复制。

根本原因：cloneFixAttribute函数只在 jQuery 的clone()方法内部被调用。如果你直接使用了原生的element.cloneNode(true)，那么cloneFixAttribute完全不会生效。这是一个常见的误解，即认为 jQuery 的修复是“全局性”的，而实际上它只作用于 jQuery 自己的 API。

排查与解决：

1. 确认调用方式：检查你的代码，是否真的在使用$(element).clone(true)？还是直接用了element.cloneNode(true)？
2. 检查 jQuery 版本：确认你使用的确实是 jQuery 1.5 或更高版本。低版本的 jQuery 不包含此修复。
3. 正确做法：始终使用 jQuery 的clone()方法，而不是原生的cloneNode。jQuery 的clone()方法内部会自动调用cloneFixAttribute，为你处理好一切。

6.3jXHR状态码不一致：status与statusText的困惑

问题现象：在error回调中，jqXHR.status是0，但jqXHR.statusText是"error"，这与预期的 HTTP 状态码（如404,500）不符。

根本原因：status为0通常表示一个网络层错误，而非 HTTP 协议层错误。这可能由以下原因引起：

• 请求被浏览器的 CORS 策略阻止。
• 请求的目标 URL 不存在（DNS 解析失败）。
• 用户主动取消了请求（如点击了浏览器的停止按钮）。
• 网络连接中断。

在这种情况下，浏览器甚至没有机会与服务器建立连接，因此无法获得任何 HTTP 状态码，status被设为0是一个通用的错误指示符。

排查与解决：

1. 检查浏览器控制台：查看是否有 CORS 相关的错误信息。
2. 检查网络面板：确认请求是否真的发出了，以及它的状态是canceled还是failed。
3. 区分错误类型：在error回调中，不要只依赖status，还要结合textStatus（"timeout","error","abort","parsererror"）和jqXHR对象本身来综合判断。例如：

$.ajax({ url: '/api/data', error: function(jqXHR, textStatus, errorThrown) { if (jqXHR.status === 0 && textStatus === 'error') { console.log('网络连接失败，请检查网络'); } else if (textStatus === 'timeout') { console.log('请求超时'); } else { console.log('HTTP 错误:', jqXHR.status, errorThrown); } } });

6.4jQuery.expando冲突：多版本 jQuery 共存时的数据丢失

问题现象：在一个页面中，通过 RequireJS 加载了 jQuery 1.4.4 和 jQuery 1.5，发现使用$.data()设置的数据，在另一个 jQuery 版本中无法读取。

根本原因：尽管 jQuery 1.5 的expando已经加入了随机数，但如果两个版本的 jQuery 是在同一个 JS 执行环境中加载的，它们的Math.random()可能在极短时间内生成相同的随机数，导致expando名称碰撞。不过，这种情况概率极低。更常见的原因是，开发者手动设置了jQuery.expando，或者使用了某些会污染全局jQuery对象的插件。

排查与解决：

1. 检查expando值：在浏览器控制台中，分别打印jQuery144.expando和jQuery15.expando，确认它们是否真的相同。
2. 避免手动设置：绝对不要在代码中手动修改jQuery.expando。
3. 最佳实践：在生产环境中，应严格避免在同一页面中加载多个 jQuery 版本。如果必须，应使用 RequireJS 的shim配置，为不同版本的 jQuery 创建独立的命名空间，或者使用jQuery.noConflict(true)来彻底释放$和jQuery全局变量。

7. 个人经验与延伸思考

我在实际项目中，曾将 jQuery 1.5 的Deferred模式，作为一种轻量级的“状态总线”来使用。例如，在一个复杂的单页应用中，我们需要协调多个异步模块的初始化顺序。与其让每个模块都去监听一个全局事件，不如为每个模块创建一个$.Deferred实例，并暴露其promise()方法。主控制器则通过$.when(module1.promise(), module2.promise(), ...)来等待所有模块就绪。这种方式，比事件总线更加清晰、更加可控，因为Deferred的状态是单一的、不可逆的，它天然地表达了“这个模块的初始化要么成功，要么失败”的语义。这种模式，后来被 Angular 的$q和 Vue 的Promise封装所继承和发扬。

重读 Gray Zhang 的这篇笔记，最大的感触是，伟大的技术演进，往往始于对一个微小痛点的极致打磨。_Deferred的诞生，不是为了发明一个新概念，而是为了解决$(document).ready()在各种边界条件下都能可靠工作的难题；cloneFixAttribute的出现，不是为了展示高超的技巧，而是为了让clone(true)这个最基本的操作，在 IE 这个最顽固的平台上也能“所见即所得”。这些看似“小”的改进，最终汇聚成了 jQuery 1.5 这座里程碑。它告诉我们，真正的工程能力，不在于能写出多么炫酷的代码，而在于能否以最朴实、最稳健的方式，将一个复杂系统中每一个毛刺都打磨光滑。这种对细节的偏执，对用户（开发者）体验的敬畏，才是一个技术产品能够穿越时间、赢得尊重的根本原因。