Go goquery Find 与 Filter 选择节点有什么区别

我第一次把商品列表解析器写成链式调用时，最容易混淆的就是 Find 和 Filter：它们都接收 CSS 选择器，返回的也都是新的 *goquery.Selection，但搜索范围完全不同。记住一句话就够了：Find 从当前选择集向下找后代节点，Filter 只在当前选择集里保留匹配节点。

官方地址：https://github.com/PuerkitoBio/goquery

如果你的起点是一个列表容器，想找它里面的商品项，用 Find；如果你已经拿到一组商品项，只想留下带有某个 class 的项，用 Filter。当选择器本身能表达完整条件时，Find("li.in-stock") 通常可以直接完成查找。

先把选择集画出来：Find 向下找，Filter 原地筛

goquery 的 Selection 可以理解成一组当前节点。官方 API 对 Find 的定义是：取得当前匹配集合中每个元素的后代，再按选择器过滤；Filter 则是把当前匹配集合缩小到符合选择器的子集。因此两者的区别不是“一个快、一个慢”，而是输入集合的空间边界不同。

例如，doc.Find("li") 会从文档选择集向下寻找所有匹配的 li 后代；而 doc.Filter("li") 只检查 doc 当前持有的节点是否匹配 li。文档根选择集本身不是这些商品项，所以后者通常得到空选择集。

项目目标：解析一个小型商品列表

这个小项目只做一件事：从一段固定 HTML 中找出商品项，再从商品项里留下已经上架的记录。HTML 里把商品放在 ul.products 下，每个商品是一个 li；上架状态用 in-stock class 表示。

机械键盘
  
无线鼠标
  
显示器支架

这里先不要急着写完整选择器。把“进入商品列表”和“在商品集合中筛状态”拆开，正好能看清 Find 与 Filter 的职责。

环境准备：引入 goquery

goquery 基于 Go 的 HTML 解析能力和 CSS 选择器库，使用前先在一个空目录初始化模块。当前 goquery 官方 README 对新版本的 Go 要求会随版本变化，项目应以你实际选择的模块版本说明为准。

# 创建小项目并加入 goquery 依赖；版本由当前模块解析
mkdir goquery-choice-demo
cd goquery-choice-demo
go mod init example.com/goquery-choice-demo
go get github.com/PuerkitoBio/goquery

核心代码：把两种选择方式放在同一个函数里

下面的代码把三种写法并列：先找所有商品再用 Filter，直接用组合选择器找上架商品，以及错误地对当前列表容器使用 Filter。代码重点是选择集的起点，不是网络抓取。

package main

import (
    "fmt"
    "log"
    "strings"

    "github.com/PuerkitoBio/goquery"
)

const html = `
机械键盘
  
无线鼠标
  
显示器支架
`

func main() {
    // 从字符串创建文档，避免把示例重点混到网络请求和缓存里。
    doc, err := goquery.NewDocumentFromReader(strings.NewReader(html))
    if err != nil {
        log.Fatal(err)
    }

    products := doc.Find("ul.products")
    allItems := products.Find("li")
    inStock := allItems.Filter(".in-stock")
    directInStock := products.Find("li.in-stock")

    // Filter 只检查 allItems 已经持有的 li，不会重新向下搜索 li。
    wrongScope := products.Filter(".in-stock")

    fmt.Println("商品总数:", allItems.Length())
    fmt.Println("Filter 后的上架数:", inStock.Length())
    fmt.Println("直接 Find 的上架数:", directInStock.Length())
    fmt.Println("容器直接 Filter 的数量:", wrongScope.Length())
}

这段代码里的 products 是容器选择集，allItems 才是商品节点集合。于是 allItems.Filter(".in-stock") 有明确的筛选对象；products.Filter(".in-stock") 检查的却是 ul.products 自身，这就是选择范围错位。

本地运行：先比较数量，再比较文本

把代码保存为 main.go 后运行：

# 运行选择范围示例；输出先用于确认集合数量
go run .

按示例 HTML，应该能观察到：商品总数为 3，Filter(".in-stock") 和 Find("li.in-stock") 都指向 2 个上架商品，而容器直接 Filter(".in-stock") 不会得到商品项。这里比较数量只是第一步，真正接入业务时还应遍历文本，确认返回的节点确实是预期层级。

// 只打印选择集中的商品文本，便于确认筛选结果没有串到别的列表。
inStock.Each(func(index int, item *goquery.Selection) {
    fmt.Printf("%d: %s\n", index+1, strings.TrimSpace(item.Text()))
})

把判断规则带回真实 HTML

遇到嵌套列表时，先问自己“我现在手里的 Selection 是什么”。如果手里是文章、卡片或列表容器，想取得内部节点，选择 Find；如果手里已经是多个同类节点，想按照 class、属性或伪类继续缩小，选择 Filter。

两者也可以组合，但组合的每一步都要能说清楚当前集合。例如 doc.Find("section.products").Find("li").Filter(".in-stock") 的语义是“找到商品区域，再取其中的 li，最后只保留上架项”。如果完整选择器已经稳定，doc.Find("section.products li.in-stock") 更短；如果业务需要在中间检查数量、读取属性或插入分支，拆成两步更容易排查。

几个容易踩坑的边界

• 把 Filter 当成再次搜索：products.Filter("li") 不会进入 products 的子节点，必须先 Find("li")。
• 选择器写得过宽：Find("li") 可能把嵌套推荐列表也带进来，必要时把容器限定到 section.products。
• 空选择集继续链式调用：goquery 返回空 Selection 时继续调用通常仍会得到空结果，应该在关键边界用 Length() 或文本检查暴露起点错误。
• 把直接 Find 和拆步 Find 混为性能结论：本文只讨论语义和选择范围，实际性能应结合 HTML 结构和真实负载单独测量。

验收清单

1. 确认每次调用前的 Selection 代表容器还是目标节点集合。
2. 需要向下进入后代时使用 Find，需要在已有集合内收缩时使用 Filter。
3. 用一个带嵌套列表的样例检查选择器是否越过了业务边界。
4. 用数量和文本各检查一次，避免只看到非空结果就误判。

常见问题

Find 和 Filter 返回的是同一种类型吗？

是，两个方法都返回新的 *goquery.Selection；区别在于新选择集来自后代搜索还是当前集合的子集。

能不能永远使用 Find("li.in-stock")？

如果容器边界和选择器条件稳定，可以这样写。需要逐段检查集合、复用中间结果或表达更复杂的业务分支时，拆成 Find("li") 再 Filter(".in-stock") 更直观。

为什么 Filter 后结果为空？

优先检查调用前的选择集。最常见原因是你还停留在容器节点，却把只存在于子节点上的 class 交给了 Filter；先 Find 到目标节点，再 Filter。

把 Find 理解成“进入后代范围”，把 Filter 理解成“收缩当前集合”，大多数选择节点的困惑就能在写代码前解决。