Go Colly 开启 Async 后，Visit 通常在请求被提交后就返回，main 不会自动等待这些异步工作。把 c.Wait() 放在入口请求提交完成之后、main 返回之前，才能让该 Collector 的工作有机会完成。不要用固定休眠代替等待，也不要在回调内部等待同一个 Collector。

官方地址：https://go-colly.org/

Async改变的是请求返回方式

Colly 支持同步和异步采集；这不是一条新版本发布消息，而是使用现有能力时容易忽略的生命周期差异。一个命令行任务循环调用 Visit，随后立即打印“结束”，可能只完成了提交，并没有收到响应或完成解析。

Go 程序在 main 返回时退出，不会等其他 goroutine。这个规则由 Go 语言规范说明。异步请求已经启动，不代表程序已经承担了等待责任。

Colly 的 官方实现为请求登记等待计数，异步模式通过 goroutine 获取响应；Wait 等待这份计数归零。它表达的是 Collector 工作边界，而不是某次 Visit 返回了 nil 就代表整项业务成功。

短生命周期任务要保留等待位置

一次性批处理、命令行导出和有限页面提取最容易遇到这个问题：入口请求提交完，主函数就没有其他阻塞点。正确的等待位置属于负责收尾的调用方，不属于响应回调。

先注册 OnHTML、OnError 等回调，再提交这一批入口 URL，最后在主函数调用 Wait。官方 并行采集示例也采用提交后等待的组织方式。如果另有 goroutine 负责未来才提交入口请求，还需要先协调生产者；Wait 不是“预知所有未来任务”的机制。

不要在 OnHTML 或 OnScraped 中调用同一个 c.Wait()：当前工作还没退出，等待者却在当前工作里，容易形成自己等待自己完成的死锁。等待前也不应提前关闭本地服务或任务所依赖的输出资源。

用本地页面写出完整等待示例

下面只请求程序自己创建的两个本地页面，避免外站权限、页面变化和选择器漂移干扰判断。在 Go module 中添加 Colly v2 依赖，将代码保存为 main.go。这里不执行示例、不提供伪造日志；读者可以按自己的环境运行。

package main

import (
    "fmt"
    "log"
    "net/http"
    "net/http/httptest"
    "sync/atomic"
    "time"

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

func main() {
    // 自有本地样本，只提供两个已知页面，不遍历外站。
    srv := httptest.NewServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
        w.Header().Set("Content-Type", "text/html; charset=utf-8")
        fmt.Fprintf(w, "
样本 %s
", r.URL.Path)
    }))
    defer srv.Close()

    c := colly.NewCollector(colly.Async(true))
    c.SetRequestTimeout(3 * time.Second)
    var titles, failed int64

    // 异步回调可能并发执行，用原子计数避免共享计数竞态。
    c.OnHTML("h1", func(e *colly.HTMLElement) {
        atomic.AddInt64(&titles, 1)
        log.Printf("标题: %s", e.Text)
    })
    c.OnError(func(r *colly.Response, err error) {
        atomic.AddInt64(&failed, 1)
        log.Printf("请求失败: %v", err)
    })

    for _, path := range []string{"/alpha", "/beta"} {
        // Visit的即时错误与后续HTTP错误分开记录。
        if err := c.Visit(srv.URL + path); err != nil {
            atomic.AddInt64(&failed, 1)
            log.Printf("提交失败: %v", err)
        }
    }
    // 所有入口请求已提交，在main返回和服务关闭前等待。
    c.Wait()
    log.Printf("收尾: 标题=%d 失败=%d",
        atomic.LoadInt64(&titles), atomic.LoadInt64(&failed))
}

代码里的三个重点可以分别核对：回调在 Visit 前注册；Wait 位于两个入口提交之后；srv.Close 使用 defer，在主函数真正收尾时关闭服务。标题计数与错误计数采用原子操作，因为不同响应回调可能并发修改它们。

读者运行时，在没有请求错误且两个页面都匹配 h1 的条件下，标题计数应为 2，失败计数为 0；两个标题日志的先后顺序没有保证。收尾日志写在 Wait 之后，不能将“访问函数返回”与“回调已经完成”混淆。

与同步模式和固定休眠比较

如果原来是同步写法，增加 Async 并不是只改一行参数：还要明确谁等待、资源什么时候关闭、哪些回调共享状态。固定 Sleep 看似能让日志出现，但网络变慢时仍可能提前退出，网络变快时又徒增等待。应围绕完成条件组织代码，而不是估算时间。

等待结束不等于业务全部成功

Wait 没有错误返回值。Visit 的即时错误和异步过程的 OnError 需要分别处理；没有 OnHTML 日志，也可能是页面未匹配、请求失败或输入不对，不一定是程序先退出。示例用独立错误计数说明这一点，不把等待结束解释成零错误。

回调如果自己再启动写数据库或落盘 goroutine，那些工作不自动属于 Colly 的等待计数。需要额外的完成协调，或者在回调内完成有限的写入。不要在后台写入还未完成时关闭文件或连接。

若修复等待后程序反而长时间不结束，查看请求超时和回调是否阻塞。Wait 本身不提供超时参数；示例设置的是请求超时，不是整个任务的截止时间。采集范围应保持有限，实际外站任务须取得授权并遵守访问规则，避免用扩大并发掩盖生命周期问题。

只调用一次Visit也要Wait吗？

在异步模式下，只要主函数可能提前结束，就应等待。请求数量为一不改变生命周期要求。

Wait要写在每次Visit后面吗？

有限批次通常在所有入口提交后统一等待；每次立即等待会削弱并发提交的意义。

为什么Wait返回后输出文件还是空的？

先区分回调未命中、请求错误和额外后台写入；Collector 的等待不替业务输出做成功判定。

解决提前退出的核心是把 Wait 放在正确的收尾边界。保留错误记录、保护共享状态，并明确额外后台任务的责任，才能让“任务结束”真正对应你的业务完成条件。