聊一个技术，如果不了解它的来龙去脉，理解总会差那么一点。jQuery的故事，要从2006年说起。那一年，一个叫John Resig的年轻开发者在纽约的BarCamp上发布了一个库，初衷很简单——让JavaScript操作HTML文档这件事，不再那么折磨人。

我当时还在用原生JavaScript跟不同浏览器的DOM API较劲，写一堆document.getElementById，还要为IE6单独写兼容代码。接触jQuery之后，那种感觉就像原本手动摇下车窗，突然换成了电动车窗——做的还是同一件事，但方式变得优雅得多。

版本迭代背后的逻辑

jQuery的版本号不是随意变化的，每次大版本的跃升，都反映了当时前端生态对浏览器的取舍。我们来看看这张版本发布的时间线。

如果你仔细看发布日期，会发现一个很有意思的现象——1.9和2.0几乎是同一时期发布的。这不是巧合，而是jQuery团队的一次重大决策。

1.x分支一直维持着对IE6/7/8这些老浏览器的兼容。在那个年代，很多公司的内部系统还跑在IE8上，这个分支的价值不用多说。

2.x分支则彻底抛弃了对IE6/7/8的支持，轻装上阵。同样的功能，打包体积更小，运行效率更高。如果你的项目面向的是移动端或现在浏览器，2.x显然是更合理的选择。

我个人在2014年前后接手过一个老项目，它用的是1.11版本，原因是客户那边还有一部分运行Windows XP加IE8的老机器。这种情况在当时并不少见，也是1.x系列能一直更新到1.12的根本原因。

jQuery的去向

2026年回看，jQuery的创始人John Resig早已不再直接参与日常维护。项目现在由Timmy Wilson主导，一个开发团队共同维护。虽然前端世界已经由React、Vue这些框架主导，jQuery的热度不如巅峰时期，但它的使用量依然是一个庞大到不可忽视的数字。

很多我们每天用的网站，后台管理系统、电商平台的老模块、甚至一些新项目里的工具方法，仍然能找到jQuery的影子。微软、谷歌这些公司的产品中也存在jQuery的代码引用。原因不难理解——它不复杂，上手快，还不需要编译构建那套体系。对于需要快速上线、团队规模不大的项目，jQuery到现在还是一个务实的选择。

jQuery为何选择了1.x加2.x这种双线策略

我自己的理解是，jQuery团队当时面对的是一个分裂的浏览器市场。移动端对性能敏感、几乎不需要兼容IE老版本；而PC端尤其是企业市场，IE8的份额还相当可观。硬要在一个版本里同时兼顾，代码会越来越臃肿。

所以他们做了一个判断：用1.x维护老浏览器用户，用2.x争取现在浏览器场景。两条线同时推进，API保持一致。这意味着开发者可以只学一套API，根据目标用户的浏览器环境，选择不同的打包分支。这在当时是一个很周到的设计。

本节课程知识要点：如果你的项目需要兼容IE8及以下版本，选择jQuery 1.x系列；如果只面向现在浏览器或移动端，选择2.x系列可以减小脚本体积、提升加载速度。

一个简短的版本应用示例

假设你在学习jQuery选择器的使用，两个版本在核心API上是保持一致的。比如这段根据输入框内容实时筛选表格行的方法，在1.11和2.1里写法相同：

$('#searchInput').on('keyup', function() {
  var keyword = $(this).val().toLowerCase();
  $('#dataTable tbody tr').each(function() {
    var rowText = $(this).text().toLowerCase();
    $(this).toggle(rowText.indexOf(keyword) > -1);
  });
});

这个示例里，代码号用到了jQuery的几个基础能力——通过ID获取元素、事件监听、获取表单值、遍历节点、条件控制显示隐藏。无论你装的是哪个版本，这些方法的行为都是一致的。这也是jQuery能大范围普及的原因：它的API设计从一开始就很稳固，版本迭代很少造成破坏性改动。

回过头看

我常对刚接触前端的人说，不用纠结学jQuery是不是“过时”。如果你以后的工内容是维护一个2015年左右启动的项目，jQuery的知识可能会让你上手快得多。再说，jQuery里那些关于DOM操作、事件委托、AJAX的核心思想，放到今天任何框架里也都有对应的影子。

学技术，说到底是在理解一种解决问题的思路。jQuery这段历史里，版本策略、浏览器兼容的取舍、API设计的稳定性，这些本身都是很值得琢磨的东西。