Go Colly 怎么给列表页和详情页使用独立回调

列表页和详情页通常不是同一种页面：列表回调负责找到详情链接，详情回调负责读取标题、作者或正文。如果把两套选择器都挂在同一个 Collector 上，代码一开始很短，页面结构稍微变化后却很难判断是哪类回调处理了当前元素。更清晰的做法是让列表 Collector 只做发现，让一个不带旧回调的 Clone Collector 专门做详情解析。

官方地址：https://github.com/gocolly/colly

这篇只讨论 Colly 的回调分工，不把示例扩展成通用爬虫框架。示例使用 Colly v2 的公开 API；图中关系是静态说明，不代表在本机执行过示例。

把列表页和详情页拆成两个职责单元

我在拆采集任务时会先问一个问题：当前回调是在“发现下一条 URL”，还是在“解析已经进入的页面”？前者属于列表边界，后者属于详情边界。两种回调的选择器、输出结构和错误处理不同，就应该有清晰的 Collector 归属。

列表回调只读取详情链接并交给详情 Collector，不能顺手把详情页字段也塞进列表对象。这样做的好处是：列表页换 CSS 选择器时只改发现逻辑，详情页字段变化时只改解析逻辑。

用 Clone 建立不带回调的详情 Collector

Colly 的 Clone 会创建 Collector 的副本，但不会带上原 Collector 的回调；官方文档还特别说明，HTTP backend、robots.txt 缓存和 cookie jar 会在两个 Collector 之间共享。这个组合很适合“共用访问基础设施、分离页面行为”的场景。

package main

import (
    "fmt"

    "github.com/gocolly/colly/v2"
)

func main() {
    // 基础 Collector 只保存访问层配置，不注册页面解析回调。
    listCollector := colly.NewCollector(
        colly.AllowedDomains("example.com"),
    )

    // Clone 不复制回调，但会共享 HTTP backend、robots 缓存和 cookie jar。
    detailCollector := listCollector.Clone()

    // 详情 Collector 只处理详情页字段，避免污染列表页的数据结构。
    detailCollector.OnHTML("article.detail", func(e *colly.HTMLElement) {
        title := e.ChildText("h1")
        fmt.Println("detail:", title)
    })

    // 列表 Collector 只负责识别详情链接，解析工作交给独立 Collector。
    listCollector.OnHTML("a.detail-link", func(e *colly.HTMLElement) {
        detailURL := e.Request.AbsoluteURL(e.Attr("href"))
        if detailURL == "" {
            return // 片段或无法解析的链接不进入详情任务。
        }
        if err := detailCollector.Visit(detailURL); err != nil {
            fmt.Println("visit detail:", err)
        }
    })

    // 这里只启动列表入口；示例地址仅用于展示调用关系。
    if err := listCollector.Visit("https://example.com/list"); err != nil {
        fmt.Println("visit list:", err)
    }
}

这里最容易误解的一点是：Clone 不意味着两个 Collector 完全隔离。它们共享底层 HTTP 访问资源和 cookie jar，所以登录态或传输配置可以延续；但回调注册表不共享，因此详情 Collector 不会自动执行列表的 OnHTML。

让列表回调只投递详情 URL

Request.AbsoluteURL 适合处理列表页面里的相对链接。直接把 href 交给详情 Collector，在相对路径、带锚点或目录层级变化时都容易得到错误地址。列表回调还应该明确忽略空地址，并把访问错误留在详情任务的边界内。

// 列表页只产生详情任务，不在这里读取 article.detail 的字段。
listCollector.OnHTML(".card", func(e *colly.HTMLElement) {
    href := e.ChildAttr("a.detail-link", "href")
    detailURL := e.Request.AbsoluteURL(href)
    if detailURL == "" {
        return // 没有可解析的详情 URL，就丢弃当前卡片。
    }

    // Visit 会继续 Collector 的采集任务；详情回调由 detailCollector 自己决定。
    if err := detailCollector.Visit(detailURL); err != nil {
        fmt.Println("detail visit failed:", err)
    }
})

如果列表页同一条详情链接出现多次，是否去重取决于采集任务的语义和 Collector 的访问记录配置。不要在列表回调里偷偷维护一套与 Colly 不一致的去重表；需要允许重复访问时，再针对具体场景配置 AllowURLRevisit，并写清楚为什么。

给两个 Collector 配置独立错误出口

列表错误和详情错误的处理目标不同。列表请求失败，可能意味着入口页不可用；详情请求失败，通常只影响一条内容。把它们分别注册到各自的 Collector 上，日志里就能保留页面类型，不必再从 URL 猜错误来源。

// 列表错误只记录入口页面，便于判断发现阶段是否中断。
listCollector.OnError(func(r *colly.Response, err error) {
    fmt.Println("list page error:", r.Request.URL, err)
})

// 详情错误包含单条 URL，便于重试或放入失败队列。
detailCollector.OnError(func(r *colly.Response, err error) {
    fmt.Println("detail page error:", r.Request.URL, err)
})

并发、错误与生命周期怎么收口

如果开启异步采集，列表回调可能在详情任务尚未完成时就返回。此时不能把程序退出当成“采集结束”，应该让负责启动任务的 Collector 在末尾等待。Colly 提供 Wait 用于等待异步请求完成；具体等待哪个 Collector，要和你的任务拓扑保持一致。

// Async 模式下，列表和详情都是独立的任务来源。
listCollector.Async = true
detailCollector.Async = true

if err := listCollector.Visit("https://example.com/list"); err != nil {
    fmt.Println("visit list:", err)
}

// 先等列表发现工作结束，再等详情 Collector 收口其异步请求。
listCollector.Wait()
detailCollector.Wait()

这里的顺序表达的是生命周期收口，不是页面回调的执行顺序：列表回调中发现的详情请求，可能已经进入详情 Collector 的队列。若任务还会从详情页继续派生更多请求，应该把最终任务归属和等待策略集中写在调度层，避免某个回调提前结束程序。

什么时候不该拆成两个 Collector

如果页面类型只有一种，或者所有 URL 都使用同一套选择器、同一个输出模型，那么单 Collector 更直接。拆分的收益来自职责差异，而不是 Collector 数量越多越好。

还要注意 Clone 的共享边界：需要完全不同的 cookie jar、HTTP client 或访问策略时，Clone 可能不是合适的隔离方式；这时可以分别创建 Collector，再显式配置各自的客户端和限制规则。反过来，如果你希望共享登录态和基础传输配置，只分离回调，Clone 就比较贴合需求。

小结

常见延伸问题是：Clone 会不会复制回调？不会；它创建的是不带回调的副本。两个 Collector 会不会完全独立？也不会，HTTP backend、robots.txt 缓存和 cookie jar 会共享。列表页一定要先于详情页完成吗？不一定，关键是把任务归属和 Wait 生命周期写清楚。