Go Colly 怎么在回调之间传递请求级业务信息

Colly 的回调是分开的函数，但请求级信息不必靠全局变量传递。最稳妥的做法是给入口请求创建 colly.Context，把 request_id、来源页或抓取批次写进去，再从 OnRequest、OnHTML、OnResponse 和 OnError 的参数读取。这样并发采集时每条请求链都有自己的业务标识。

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

用 Colly Context 建立请求级数据链

入口请求和后续链接应先分配一个上下文。Put 可以写入任意值，但 Get 只适合读取字符串；数字、结构体或切片应使用 GetAny 并做类型断言。以下示例把请求编号写入 Context，并让后续回调复用它。

package main

import (
    "fmt"
    "log"

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

func main() {
    c := colly.NewCollector()

    c.OnRequest(func(r *colly.Request) {
        // OnRequest 只负责读取本次请求的业务字段，不使用全局变量。
        log.Printf("start id=%s url=%s", r.Ctx.Get("request_id"), r.URL)
    })
    c.OnHTML("a[href]", func(e *colly.HTMLElement) {
        // HTMLElement.Request 指回触发当前元素回调的原请求。
        id := e.Request.Ctx.Get("request_id")
        source := e.Request.Ctx.Get("source")
        log.Printf("link id=%s source=%s href=%s", id, source, e.Attr("href"))
    })
    c.OnResponse(func(resp *colly.Response) {
        // Response.Request 让响应回到同一条请求上下文。
        log.Printf("done id=%s status=%d", resp.Request.Ctx.Get("request_id"), resp.StatusCode)
    })
    c.OnError(func(resp *colly.Response, err error) {
        // 出错时优先保留请求编号，便于把错误和业务记录关联起来。
        if resp != nil && resp.Request != nil {
            log.Printf("failed id=%s err=%v", resp.Request.Ctx.Get("request_id"), err)
        }
    })

    ctx := colly.NewContext()
    ctx.Put("request_id", "job-20261013-001")
    ctx.Put("source", "catalog-entry")
    // 入口 Context 随请求传入，后续回调读取同一份请求级数据。
    if err := c.Request("GET", "https://example.com/catalog", nil, ctx, nil); err != nil {
        log.Fatal(err)
    }
}

这里的关键不是把所有状态都放进 Context，而是只放“这条请求链需要知道”的字段。比如批次号、入口类型和可关联的请求 ID 合适；Collector 级限速器、全局缓存和可变统计表不合适。

回调读取规则要和字段类型匹配

常见故障是用 Get 读取整数或结构体，结果触发类型断言错误。可以把字段约定写成小表，调用点也更容易复查：

如果字段可能缺失，先判断 GetAny 是否为 nil；如果字段来自不可信输入，不要把它直接当成结构体指针使用。并发模式下，Context 自身的读写有锁，但 Context 中保存的 map、slice 或指针对象仍需要业务层自己保证安全。

并发与子请求的继承边界

在 OnHTML 中调用 e.Request.Visit 时，Colly 会创建后续请求并保留当前 Context，这正适合给详情页延续入口编号。如果子请求代表全新的业务任务，不要无条件复用；可以复制后改写字段，避免修改原请求正在使用的值。

c.OnHTML("a.detail", func(e *colly.HTMLElement) {
    // Visit 会继承当前 Request.Ctx，详情页仍能关联同一入口任务。
    if err := e.Request.Visit(e.Attr("href")); err != nil {
        log.Printf("visit detail failed id=%s err=%v", e.Request.Ctx.Get("request_id"), err)
    }
})

func forkContext(src *colly.Context, page int) *colly.Context {
    // Clone 复制键值关系；不要把它当成深拷贝来保护内部指针。
    dst := src.Clone()
    dst.Put("page_no", page)
    return dst
}

Clone 适合“保留公共字段、为子任务增加字段”的场景，但它不会自动复制 Context 里指向的可变对象。若 trace 指向共享结构体，仍需复制结构体本身或只传不可变快照。

把业务关联和请求取消分成两条线

Colly 的 Context 是回调之间的数据袋，不是标准库的 context.Context。需要超时、取消或把取消信号传入 HTTP 请求时，应在创建 Collector 时使用 colly.StdlibContext：

ctx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
defer cancel() // 释放计时器，超时后让 Collector 的 HTTP 请求退出。

c := colly.NewCollector(colly.StdlibContext(ctx))
// 业务字段仍放在每个 Request 的 colly.Context 中，两套 Context 各司其职。

最后按四项检查：请求编号是否在入口创建；错误回调是否处理空响应；非字符串字段是否经过 GetAny；共享指针是否有明确的并发策略。满足这四点，回调之间传递业务信息就不会依赖脆弱的全局状态。

相关问题

Colly Context 能替代标准库 context.Context 吗？

不能。前者服务于回调间传值，后者负责取消、截止时间和请求生命周期。

Request.Visit 会丢失入口字段吗？

正常情况下不会，Colly 会沿用当前 Request 的 Context；若手动创建全新入口请求，则要重新传入 Context。

Get 和 GetAny 应该怎么选？

字符串字段用 Get；整数、结构体、切片等其他类型用 GetAny，并在读取后检查类型和空值。