jQuery筛选方法梳理：后代、祖先、兄弟与集合收窄

写这套jQuery筛选方法梳理的起因是我在带几位刚转前端的朋友看项目代码时发现一个现象很多人能把$(.box .item)这种CSS选择器写得飞起但一看到.find()、.closest()、.nextAll()这类筛选方法就开始懵。也不是不会用就是每次都要查一遍文档用完就忘。后来我琢磨了一下问题不在记忆力在于大家习惯把选择器语法和筛选方法放在一个维度里去记结果越记越混。实际上筛选方法的核心是基于当前元素集合做定向查找与收窄它和CSS选择器那种一次性的静态定位完全是两种思维方式。这篇文章就把jQuery筛选方法按实际使用场景重新拆一遍——向下找后代、向上找祖先、同级找兄弟、范围限定查找。每个方向我会先讲方法之间的差别再给一段能直接抄的代码最后聊聊我在真实项目里踩过的坑。适合刚接触jQuery的人建立方法体系也适合写过一阵子但总在几个方法之间犹豫的人查漏补缺。1. 筛选方法为何不能当选择器用先理解jQuery对象是一个集合很多新手第一次看到$(ul li)和$(ul).find(li)结果一样就觉得这俩是等价物后面就随便混用了。这种理解会埋下隐患因为两者的执行逻辑完全不同$(ul li)是浏览器原生querySelectorAll一次扫完整个DOM返回的是所有ul内部li的静态集合而$(ul).find(li)是先拿到所有ul再针对这个集合逐层往下检索。结果虽然经常一致但过程不一样性能特征也完全不一样。1.1 筛选方法操作的是集合而不是单个元素jQuery选择器返回的永远是一个类数组对象哪怕只有一个元素命中它也是长度为1的集合。筛选方法的设计初衷就是对这个集合做二次操作可以筛选、可以扩展、可以截取、可以按方向遍历。举一个最直观的例子// 选中页面所有div const $divs $(div); // 从中挑出 class 包含 main 的那一个 const $main $divs.filter(.main); // 再从这个结果往下找所有 p 标签 const $paragraphs $main.find(p);这段代码里每一个方法都作用于集合而不是单个元素。写惯了原生JS的人可能会下意识地想document.querySelectorAll(div)返回的NodeList只能用forEach遍历想筛选得自己写循环。jQuery筛选方法的价值就在这——用方法声明意图把遍历细节封装掉。1.2 筛选和选择的边界在哪我个人的理解是选择器负责从整棵DOM树里定位它面对的是全部文档筛选方法负责从已有集合里再挑一遍它面对的是已经拿到的元素集合。这个边界想清楚之后很多接口设计就很好理解了。选择器$(.item)、$(div p)、$(input[typetext])本质是CSS选择器语法。筛选方法.filter()、.not()、.eq()、.first()、.last()、.slice()本质是对当前集合的过滤与截取。关系方法.children()、.find()、.parent()、.parents()、.closest()、.siblings()、.next()、.prev()等本质是在集合基础上按DOM树关系做扩展。实际开发里最容易被混用的就是第三类关系方法因为它们看起来太像是在写选择器了。比如$(this).parent(.item)这种写法很多人以为是在查找满足选择器的父级但jQuery的实际行为是先取所有父元素再从中筛选匹配选择器的那一个。如果父元素根本不匹配.item返回的就是空集合。这个先按关系取、再按条件筛的嵌套逻辑正是前面说的集合思维的核心体现。理解这层之后接下去的几个方向分类就顺理成章了我们不是为了记API而记API而是为了在合适的场景里知道自己手里拿的是哪个方向的集合才知道该调用哪一组方法。2. 向下找后代children与find看起来像性格完全不同向下查找有两个主力方法.children()和.find()。很多人问我这俩到底有啥区别我一般会反问一句你要儿子还是所有后代这句玩笑话其实点到了要害。2.1 children只认亲儿子find一路挖到底.children()只遍历选中的子元素也就是DOM树里的直接子节点.find()则遍历所有后代节点包括子、孙、重孙。差异在嵌套层级多的页面里特别明显。div idcontainer div classbox span classtag一级标签/span div classinner span classtag二级标签/span /div /div span classtag容器直属标签/span /divconst $container $(#container); // children 只拿到 div.box 和 span.tag容器直属 console.log($container.children().length); // 2 console.log($container.children(.tag).length); // 1只算直属span // find 拿到所有后代中的 .tag console.log($container.find(.tag).length); // 3含内层那个如果页面结构是已知的、固定的children()的执行路径更短性能也更好。find()在嵌套层级深、页面节点多的情况下往往要一路下探到目标层开销会明显增大。别看这个差异很小在列表页、表格页这种动辄几千个节点的场景下方法选错直接影响首屏渲染速度。2.2 什么时候必须用children什么时候只能find我总结了三条实践规律基本可以覆盖日常场景结构严格受控时用 children。例如渲染出来的组件卡片层级固定找内部按钮直接用.card-wrap.children(.btn)语义清晰还快。要找的元素嵌套层级不固定时用 find。比如富文本编辑器渲染出来的内容里面可能套了多层div你想拿到所有图片只能.find(img)。最好不要在 children 后面加我以为它会递归的期待。曾经有人写.children(.list-item)期望拿到全部列表项结果只拿到直接子级里那一个包裹层排查半天才发现是理解问题。还有一种常见的组合用法是用find()配合排除自己的需求。比如处理树形菜单展开子目录时需要拿到当前节点的所有后代菜单项又不希望包含当前节点自身这时候$(current).find(.menu-item)就是最直白的写法。2.3 向下查找在真实项目里的性能差异我用一个实际场景演示过两者的差距。某个后台管理系统的侧边栏菜单结构大致是三层嵌套菜单项总共有两千多个。一次全量渲染之后分别执行$(#sidebar).children(.menu-link)和$(#sidebar).find(.menu-link)在普通电脑的Chrome里用performance.now()简单计时方法命中数量耗时十次均值children全部直属菜单链接约0.8msfind全部层级的菜单链接约2.4ms差距看上去只有1.6毫秒但在事件委托、逐项绑定的循环操作里这个差距会被放大。有一次做菜单高亮联动我在find出来的集合上对每个元素做了一次样式操作加上样式计算和重绘总耗时直接超过30ms。换成children组合逐层定位之后降到了10ms以内。这件事给我的教训是别小看DOM查询的积累效应尤其在做批量操作时。3. 向上找祖先parent、parents、closest三者必须分清边界向上查找是事件委托和表单校验里最常用的方向但也是新手最容易写错的一类。难点在于parent()、parents()、closest()三个方法都能往上走可它们的行为差异非常细微不该混为一谈。3.1 从最近一层到全部祖先再到满足条件的最近祖先先看三者的核心差异.parent()只向上走一层返回父元素集合。.parents()一直走到文档根节点返回所有祖先元素集合。.closest()从当前元素开始向上查找第一个匹配选择器的祖先包含自身。其中closest()最特别的地方在于它包含自身。换句话说如果当前元素本身就匹配传入的选择器closest()会直接返回这个元素而不会继续向上找。这是和parents().first()最大的不同。div classcard div classcard-body button classdel-btn删除/button /div /divconst $btn $(.del-btn); $btn.parent(); // div.card-body $btn.parents(); // [div.card-body, div.card, body, html] $btn.parents(.card); // [div.card] $btn.closest(.card); // [div.card] // 如果当前元素本身匹配选择器closest直接命中自身 $(.card).closest(.card); // [div.card]不是外层 $(.card).parents(.card); // []因为祖先里没有.card最后那两行是我反复强调的例子。很多人写点击事件时想找当前按钮所在的卡片区域如果按钮自身恰好也符合某种特征closest()和parents(.xxx).first()的结果就可能不一样。理解包含自身的规则才能避免这种边界情况下的bug。3.2 事件委托里为什么首选closest在做事件绑定时几乎所有的由内向外找容器需求都应该用closest()原因有三closest()在浏览器内部有原生实现性能好于parents()再手动过滤。它天然支持当前元素就是目标容器的情况代码更简洁。语义直白$(e.target).closest(.row)念出来就是找到最靠近事件来源的那一行可读性最好。真实项目里的典型写法是下面这样。一个商品列表每行有删除按钮点击后要操作整行数据$(#list).on(click, .delete-btn, function (e) { // 千万别在这里直接拿 $(this)因为this是按钮本身 const $row $(this).closest(.product-row); const productId $row.data(id); if (confirm(确定删除该商品吗)) { // 执行删除逻辑 $row.remove(); } });这里用closest()拿到按钮所在的完整行再通过>const $current $(.current-page); const chain $current.parents().addBack().map(function () { return this.tagName.toLowerCase() || $(this).attr(class); }).get(); console.log(chain); // 例如 [html, body, div.breadcrumb, span.current-page]另外在做判断元素是否在某个容器内部时.parents().is()组合也能用。比如拖拽上传组件里判断拖入的目标是否在允许接收的区域内$uploadZone.on(dragover, function (e) { const $target $(e.target); if ($target.parents(.drop-zone).length 0) { return; // 不在允许区域内忽略 } // 执行拖拽预览逻辑 });这里也可以用closest(.drop-zone)但从可读性上说parents().length这种看看祖先里有没有这类元素的表达更接近直觉。两种写法都行我倾向于closest()更规范但如果团队里有人对parents更熟悉也不至于出问题只要别在性能敏感循环里用它就好。3.4 向上查找最容易踩的三个坑parent()后面不加选择器导致误判$(this).parent()拿的是直接父级不管父级长得像不像你想要的那个。如果DOM结构发生微调代码就悄悄失效了。解决办法是养成加选择器的习惯例如$(this).parent(.item)至少能提前发现问题。误以为parents()返回的是最近一个有些人在parents(.box)后面直接调用.data()结果拿到的是一大堆匹配元素中的第一个碰巧是外层包裹容器数据取错了都不知道。在事件委托里用$(this).parents()处理动态内容如果目标元素是动态插入的parents()返回的集合顺序可能和预期不一致建议先用closest()明确最近的匹配祖先这个语义。4. 同级找兄弟next、prev、siblings之间的方向感同级查找是四个方向里最容易绕晕的一个。原因是它的方法数量最多而且方向和过滤两个维度叠加在一起不画图很容易混乱。其实只要抓住一条主线先分清自己是往后面、往前面还是两边都要再决定用哪个方法。4.1 从相邻开始next与prev只认紧挨着的那一个.next()返回当前元素的下一个同级元素.prev()返回上一个两者都只认紧挨着的那个不会跳过中间的其他元素。ul li classapple苹果/li li classbanana香蕉/li li classcherry樱桃/li /ulconst $banana $(.banana); $banana.next(); // li.cherry $banana.prev(); // li.apple $banana.next(.apple); // []因为下一个是cherry不匹配apple最后一行需要注意next()可以传入选择器作为过滤条件但过滤的是下一个元素是否匹配而不是跳过不匹配的往下找下一个匹配的。所以$banana.next(.apple)返回空集合尽管苹果确实存在于它后面的DOM树中——它不在紧挨着香蕉的下一个位置上。想要往后找第一个匹配的元素需要的是.nextAll()配合.first()或者.nextUntil()。4.2 双向铺开siblings拿全部兄弟再过滤.siblings()返回除自身以外的所有同级元素然后可以再传入选择器缩小范围。这个方法的场景很典型比如选项卡切换、手风琴菜单$(.tab).on(click, function () { const $this $(this); // 其他兄弟取消激活状态 $this.siblings(.active).removeClass(active); // 当前项激活 $this.addClass(active); });removeClass本身对空集合是无害的所以即使某个时刻没有兄弟处于激活状态这段代码也不会报错。这算是jQuery一个贴心的地方很多链式写法不用先判断集合是否为空直接往下调方法就行。4.3 连续区间nextAll、prevAll和nextUntil、prevUntil比next()和siblings()再进一步的方法是处理连续的一段兄弟区间。.nextAll()当前元素后面的所有同级元素。.prevAll()当前元素前面的所有同级元素。.nextUntil(selector)从下一个开始一直到遇到匹配selector的元素为止不包含那个元素。.prevUntil(selector)往前同理。举一个我实际处理过的例子。编辑后台的文章列表每一行是一个div.row其中某一行处于预览模式要在它后面插入一个操作条直到遇到下一行的分隔线const $curRow $(.row.preview); const $delimiter $curRow.nextAll(.divider).first(); $curRow.nextUntil($delimiter.is(:visible) ? $delimiter : null) .addClass(preview-space);这个例子稍微绕了一点但它说明了一个关键能力nextUntil可以控制截断点这在动态渲染的列表里特别实用。用nextAll()拿后面全部再用nextUntil()拿到某一段为止两种粒度配合起来基本覆盖了所有连续区间的需求。4.4 同级方法最容易搞错的两个点next()与nextAll()的过滤语义不同next(.cls)是检查下一个元素是否匹配nextAll(.cls)是从后面所有元素里筛出匹配的。前者不跳过后者会跳过。很多人第一次在这上面栽跟头就是以为next(.cls)也能跳过去找。siblings(.cls)会把前面所有后面所有合在一起它的返回顺序是DOM树顺序而不是从自己开始向两边扩散。如果你需要按照离自己最近的优先级操作兄弟得自己排序或分两次取先prevAll()再nextAll()。5. 范围限定查找filter、not、eq、slice这些收窄手法别混用前三个方向解决的是往哪个方向找第四类方法解决的是在当前集合里怎么继续收窄。这类方法数量不多但每个的使用场景差异很大而且和查找方向互相组合是筛选方法里的高阶玩法。5.1 eq与slice按位置取不按条件筛.eq(index)从集合中取出指定索引位置的元素索引从0开始支持负数表示从末尾往前数。.slice(start, end)则是截取一段区间和数组的slice行为几乎一致。const $items $(.list li); // 假设有8个li $items.eq(0); // 第1个 $items.eq(-1); // 最后1个 $items.slice(2, 5); // 第3个到第5个索引2、3、4 $items.slice(-3); // 最后3个.eq()比.first()、.last()更通用后两者本质就是eq(0)和eq(-1)的语法糖。在分页器高亮、轮播图取当前页元素这类按位操作的场景里eq()是绝对主力。5.2 filter与not按条件筛支持函数和选择器两副面孔.filter()保留匹配条件的元素.not()删除匹配条件的元素两者逻辑正好相反。它们最大的特点是条件不仅可以是选择器字符串还可以是一个返回布尔值的函数。函数形式在处理复杂业务条件时尤其好用。const $products $(.product); // 选择器形式筛出优惠中的 const $onSale $products.filter(.on-sale); // 函数形式筛出价格大于100且库存不足的 const $hotItems $products.filter(function (index) { const $el $(this); const price Number($el.data(price)); const stock Number($el.data(stock)); return price 100 stock 5; });函数形式里的this指向遍历中的DOM元素索引通过参数传入。这是jQuery筛选方法里最接近原生JavaScript filter的写法也是我强烈建议新手尽早掌握的能力——一旦熟练很多复杂的筛选需求都不用再造一堆条件class了。.not()的典型场景是排除某项。比如表格行点击时要排除掉带有>$tableRows.not([data-disabledtrue]).on(click, function () { // 只有可点击行才会进入这里 handleRowClick($(this)); });5.3 组合拳方向查找 范围收窄一链到底筛选方法最强大的地方在于它们可以连续使用形成一条查找—收窄—再查找的流水线。我写过一个表格列权限控制的需求根据用户的权限配置动态决定哪些列可以显示。当时的思路就是先定向再收窄const $table $(#data-table); const allowedColumns [0, 2, 3, 5]; // 配置中心下发的可见列索引 $table.find(tr).each(function () { const $row $(this); // 当前行里的所有单元格按列索引收窄 $row.children(td, th).filter(function (index) { return allowedColumns.indexOf(index) -1; }).hide(); });这段代码先用find(tr)向下找到所有行再children(td, th)拿到每行直属单元格最后用filter(函数)把不在白名单里的列隐藏。整个过程没有任何循环嵌套的DOM遍历代码全靠筛选方法链完成读起来逻辑非常顺。5.4 使用filter函数时注意this指向与性能函数形式的filter()会在每次调用时重建一个jQuery对象来包装当前元素这在集合很大时会有额外的内存开销。如果只是简单条件判断尽量用选择器参数必须用函数时在函数体开头用let $el $(this)缓存避免在循环里重复调用$(this)多次。另外要注意filter()函数里如果使用了外部的变量要小心闭包陷阱。比如在循环里给多个元素分别做不同阈值的过滤如果变量是var声明的会全部取到最后一次循环的值。现在写前端基本都用let或const但老项目里还是能看到var的影子遇到时要留个心眼。5.5 范围限定方法的优先级与短路行为当你连写多个筛选方法时比如.filter(.a).not(.b).eq(0)执行的顺序是从左到右逐步收窄的。filter和not之间没有一步到位的合并写法每一步都会产生一个中间集合。虽然在绝大多数场景下这不影响最终结果但如果你要处理的是超大集合比如上万行表格建议尽量用CSS选择器把能合并的条件写在一个filter()里减少方法链的长度。6. 筛选方法链式调用中的性能意识与可维护性前面把一个一个方法拆开讲了最后这部分聊聊把它们串起来之后的事。筛选方法最大的魅力是链式调用但链式调用也容易写出看着很酷、跑起来很慢、改起来想骂人的代码。我有几个经验可以分享。6.1 先缓存jQuery对象别每次都重新查这是jQuery性能优化里最经典的一条但在筛选方法链的场景下特别容易被忽略。很多人这样写// 反例每次点击都重新查一遍 $(.nav-item).on(click, function () { $(.nav-item).removeClass(active); $(this).closest(.nav-item).addClass(active); });这段代码本身逻辑没错但$(.nav-item)在每次点击时都会重新执行一次DOM查询。如果导航项有几百个点击频率又高性能损耗就上来了。改成缓存之后const $navItems $(.nav-item); $navItems.on(click, function () { $navItems.removeClass(active); $(this).closest(.nav-item).addClass(active); });因为绑定事件的目标集合和操作的目标集合一致可以在初始化时一次性查好之后所有点击都复用同一个$navItems。这里还要注意removeClass作用于缓存集合是安全的因为类名的增删不影响元素的集合身份。6.2 能缩短链条的场合别写旅游式长链我见过一种代码风格喜欢把一堆方法连在一起比如$(.list).find(.item).filter(.active).siblings().addClass(muted);单行看每步都对但连在一起后阅读者需要先把整条链在脑子里拆开再理清每一步返回的是什么。这就像一口气说了五个转折的句子交流效率很低。我更推荐的重要经验是把复杂链条拆成有名字的中间变量。const $activeItem $(.list .item.active); const $siblings $activeItem.siblings(); $siblings.addClass(muted);这样写虽然多了一两行但每一行都在表达一个清晰意图。尤其是项目进入维护期之后换个人来看代码中间变量比一串方法链友好得多。6.3 链式写法在集合为空时的安全性jQuery筛选方法一个很大的好处是在空集合上继续调用方法不会报错。这在链式场景里非常省心。但反过来也要注意这种安全有时会掩盖问题。比如你写$(.not-exist).find(.child)返回空集合后面的方法全都静默执行页面也没报错。如果这是业务逻辑本不该发生的情况问题就不容易被发现。我的处理习惯是在关键业务节点加一个空集合判断const $rows $(.table .data-row); if ($rows.length 0) { // 数据为空或选择器写错了尽早暴露 console.warn([Table] 未找到任何数据行请检查选择器条件); return; }这种防御性写法不花多少成本但在排错时能省下大把时间。尤其是合作项目里某个类名被重构掉、DOM结构变动导致选择器失效时控制台里的warn就是第一道线索。6.4 筛选举动的可读性建议给筛选条件取名最后分享一个小技巧当筛选条件比较复杂时把条件抽成有业务含义的变量或函数。比如找出库存预警商品这个需求如果散落在代码里写.filter(function() { ... })每次阅读都要重新解析那段判断逻辑。建议把判断逻辑抽出去function isLowStock() { const price Number($(this).data(price)); const stock Number($(this).data(stock)); return price 100 stock 5; } const $warnItems $(.product).filter(isLowStock);filter(isLowStock)读起来几乎是自然语言筛选出低库存商品。这个命名习惯比任何注释都更容易维护。6.5 再聊一个实战中活用的筛选场景写文章前我还顺手整理了一个小轮子实现当前高亮项展示邻居的效果。比如一个横向滚动的商品推荐位需求是亮点中间的商品同时把相邻两边的商品稍微放大一点形成焦点左右陪衬的视觉。用筛选方法实现起来很清爽function highlightFocus(index) { const $items $(#gallery .g-item); $items.removeClass(is-focus is-adjacent); $items.eq(index).addClass(is-focus); $items.eq(index - 1).addClass(is-adjacent); $items.eq(index 1).addClass(is-adjacent); }eq()在这里提供了精确的位次访问而removeClass操作全部集合又保证状态重置。整个函数没有一行DOM遍历全是集合思维下的同一批元素换个状态这就是筛选方法链的魅力所在。写在最后做这个分类梳理时我又把jQuery源码里的筛选部分翻了一遍有一点感触比较深这些筛选方法虽然看起来繁杂但底层的设计逻辑非常一致——先定位集合再通过方向、条件、位置三个维度去变换集合。只要脑子里有集合这个概念children和find的差别、parent和closest的差别、next和nextAll的差别就都不需要死记硬背了。我个人在实际操作中的体会是与其把API列表背熟不如在项目里刻意多写几次找祖先 收窄 批量操作的链式代码写顺手之后自然就分清了哪个方法该在哪个场景出现。以后就算某天项目升级要移除jQuery这套按关系定向、按条件收窄的思维也能平移到原生DOM API和函数式工具上不算白学。