一搜 “Colly”，最常见的形容词永远只有一个：快。Go 爬虫很快，因为它可以编译；很快，因为它不需要浏览器介入。但几乎没人拿出具体数字来说明它到底快到什么程度。
所以我不再只听口号了。于是我搭了一个小型测试站点，把 Colly 编译后对着它跑，看看这个库真实表现如何——在真实页面上的召回率、遇到 500 错误时怎么分流、深度受限的抓取会跑到多远。先说结论：静态内容抓取召回率满分，500 错误也准确落到了该去的地方，而一次深度限制抓取从单个静态二进制程序出发，在没有浏览器的情况下跑到了 17 个页面。至于那些 JavaScript 渲染页面，它同样返回了干净的 0——而这恰恰是“快”这个说法里最常被忽略的部分。
Colly 到底是什么，不是什么
Colly 自称是 “Golang 的优雅爬虫和抓取框架”，这句话比看上去更有分量。它是一个 Go 库——截至 2026-07-09，gocolly/colly 大约有 ~25.4k stars，采用 Apache-2.0 许可证。它不是一个下载后直接输入 URL 就能用的命令行工具。你需要写 Go 代码，导入这个包，配置几个回调，然后把结果编译成一个可执行文件。
它的工作模型是事件驱动的，这也是很多从“请求-解析”思路过来的人容易卡住的地方。你不是把响应一行一行遍历后再把字段抠出来；你是把处理器挂到 Collector 上，让库在遍历页面时触发它们。OnHTML 会在匹配到 CSS 选择器时执行你的提取逻辑。OnResponse 会把原始响应体交给你，这在返回 JSON 而不是 HTML 时特别有用。OnError 则负责捕获请求失败。抓取流程也是同样的逻辑：在链接处理器里对发现的 URL 调用 Visit()，Colly 会把它们排入队列，而 MaxDepth 决定这趟抓取能跑多远。回调、访问队列、深度限制、编译后的静态二进制。没有解释器，没有运行时，也没有常驻内存的无头 Chrome。
回调模型，以及它为什么会改变你的抓取体验
这些回调基本就是这款工具的性格所在，所以值得慢一点讲。我的所有测试都依赖下面这三个。
OnHTML(selector, handler) 是最常用的。你可以把它注册到 .product 或 article p 上，Colly 在解析 DOM 时会对每个匹配元素调用你的处理函数。结构化提取就发生在这里，而且表达方式很直观——你写的是“想要什么”，而不是“怎么循环去拿”。
OnResponse(handler) 的层级更低，它直接给你网络返回的原始字节。目标站点如果返回的是 JSON 而不是网页标记，你根本不用碰 DOM，直接自己反序列化响应体就行。正是这个回调，让 Colly 在我的测试里可以不用解析任何 HTML，就处理了一个 JSON API。
OnError(handler) 是那种大家总会忘记，直到凌晨 3 点爬虫挂掉时才想起来的回调。请求失败时它会触发，并把响应信息交给你，这样你可以查看状态码并决定下一步怎么做。一个悄悄吞掉失败的爬虫，往往比一个明确报错的爬虫更糟；Colly 两种情况都不是，这一点在无人值守任务里比听起来更重要。
此外，还有两个对实际运维很关键的能力。MaxDepth 可以限制抓取深度，所以跟链接的 collector 不会一路跑到全网；而编译结果是一个独立的静态 Go 二进制文件——编译一次得到一个文件，没有运行时依赖，丢到服务器上或 CI 任务里就能跑。如果你曾经在一台新机器上因为 Python 虚拟环境折腾掉一个下午，你就会知道这种部署方式不是注脚，而是真正的优势。
环境搭建——没人提起的 Go 工具链
依赖很简单，但有一个关键前提，所以在你安装之前先说清楚。我测试的机器上原本根本没有 Go，而 Colly 是 Go 库，所以第一步是先把工具链装到机器上——我通过 Homebrew 安装了 Go 1.26.5。如果你的团队本来就不在 Go 生态里，这才是真正的摩擦点。不是库本身，而是它在编译前必须存在的语言环境。
Go 装好之后，拉取 Colly 就很顺了。go get github.com/gocolly/colly/v2 直接解析到 v2.3.0，没有任何波折——没有浏览器，没有无头环境，最后只有编译好的二进制文件。把它和那些先装解析器、再在第一次抓取时因为缺失一堆依赖而崩掉的 Python 爬虫放在一起对比，这种体验简直出人意料地“平淡”。而这里的“平淡”其实是夸奖。
这里有一个精确说明，提前讲明白，因为你如果真去查，很容易被搞糊涂。我测试时用的最新版模块是 Go proxy 上的 v2.3.0，发布于 2025 年 12 月；而 GitHub 上最新的 tag release 是 v2.2.0，发布于 2025 年 3 月。也就是说，我实际测试的代码——v2.3.0——比仓库 Releases 页面展示的版本更前。这个差异是 Go modules 和 GitHub tags 随时间分叉造成的，不代表有什么问题。只要你别在 go get 和 Releases 页面显示不同数字时愣住就行。
实测——“快”背后的数字
我把 Colly 跑在一个基于 Go httptest 搭建的自包含测试服务上，外加两个公开演示站点，所以这些行为是可以复现的，而不是我在讲故事。结果如下。
| 测试 | 目标 | 结果 |
|---|---|---|
| 静态目录 + 分页 | 本地测试站点 | 12/12 个商品，召回率 1.0 |
| 文章提取 | 本地测试站点 | 标题 + 3/3 段落 |
| 动态 JSON API | 本地测试站点 | 通过 OnResponse 提取 8/8 条数据，召回率 1.0 |
| HTTP 500 处理 | 本地测试站点 | 路由到 OnError，状态码 500 |
抓取图谱（MaxDepth 2） | 本地测试站点 | 17 个页面 |
| Books to Scrape | 公开演示站点 | 20 个商品 |
| 动态页面（无 JS 渲染） | 本地测试站点 | 0 个卡片（符合预期） |
| Quotes JS（不渲染） | 公开演示站点 | 0（符合预期） |
从上往下读，整个结果就很连贯了。静态提取非常干净——目录页 12 个商品全部拿到，文章 3 个段落也一个不漏，全部由 OnHTML 选择器驱动。JSON API 测试甚至都没打开 HTML 解析器：OnResponse 直接把响应体交给我，我自己反序列化后，8/8 条数据全部拿到。500 测试是我最看重的一项，因为它决定了一个爬虫能不能放心挂着跑一整晚，而不是一遇到错误就悄无声息地失败——Colly 把失败正确送进了 OnError，状态码清晰可见，没有崩溃，也没有静默丢失。公开的 Books to Scrape 演示站点上，它也顺利抓到了 20 个商品，没有任何特别处理。
真正的重点是抓取结果，我想准确地表达这一点。一个设置了 MaxDepth(2) 的 collector，在跟随链接并将其解析为绝对 URL 后，穿过我的测试图谱，最终到达了 17 个页面。这就是“fast Go crawler”终于被具体页面数量钉住，而不只是停留在印象里的版本。不过要注意措辞——这里是“在深度为 2 的抓取下到达了 17 个页面”。这个“2”是我测试脚本里的计数方式，用来说明我如何配置运行；我并不是在断言 Colly 内部有一个严格的契约，保证“恰好深度 2，绝不多一层”。更准确、也可验证的说法是：在深度上限为 2 的情况下，这次抓取遍历了图谱并到达了 17 个页面。
接下来是上限，这也是那些“它真的好快”的文章通常会沉默的地方。Colly 不会执行 JavaScript。我把它指向一个 JavaScript 渲染测试页面，结果拿回了 0 个卡片；再把它指向公开的 Quotes to Scrape JS 页面，还是 0。这既不是 bug，也不是缺陷指责。Colly 本质上是一个 HTTP 爬虫——它下载并解析 HTML，但从不启动浏览器来运行客户端脚本。和 Scrapy 以及其他偏 HTTP 的爬虫一样，如果你要的内容只会在 JavaScript 执行后出现，那么 Colly 每次都会给你空结果，纯粹的速度也改变不了这一点。要么给它配一个渲染器，要么直接选一个自带浏览器渲染的工具。
我也得老实说明我没测什么，免得有人把结果往证据之外硬延伸。我没有测试异步 collector、限速和礼貌策略、代理轮换，也没有测试队列和存储后端。这些能力 Colly 都有。我测的是提取与抓取的核心能力，不是横向扩展的基础设施。README 声称单核吞吐可达到每秒一千多次请求，这个数字来自项目方自己；我测的是页面数量和召回率，不是吞吐量，所以当我说“快”时，指的是我实际测到的 Go 编译提取路径，而不是一场我没跑过的 Scrapy 对比基准。
优点与缺点
优点：
- 静态页面提取召回率满分——通过
OnHTML抓到 12/12 个目录商品和 3/3 段落。 - 通过
OnResponse可以直接处理 JSON，无需解析 DOM——8/8 条 API 数据全部拿到。 - 错误路由准确——500 状态正确进入
OnError，状态码暴露清楚，没有崩溃。 - 一个 collector 配合深度限制就能抓到 17 个页面。
- 单个静态 Go 二进制，零运行时依赖——部署和运维体验非常好。
- Apache-2.0 许可证宽松。
缺点：
- 不执行 JavaScript——客户端渲染内容直接返回 0，没得商量。
- 需要 Go 工具链；如果团队本来不在 Go 生态里，开始写爬虫前就要先付出环境搭建成本。
- 最新模块版本（
v2.3.0）比 GitHub 上最新 tag（v2.2.0）更新，这会让看 Releases 页面的人困惑。 - 输出逻辑要你自己写——Colly 提供的是回调，不像 Scrapy 那样自带数据集或导出器。
- 异步、限速、代理和队列后端虽然存在，但这里没有测试；这里的“快”指的是我测到的提取路径，而不是正面对比的吞吐数字。
Colly 适合谁，又该跳过谁
如果你本来就在写 Go，并且要高速抓取 HTML 或 JSON 驱动的网站，Colly 很适合你。如果你心目中的“干净部署”就是把一个二进制文件复制到机器上直接跑——没有解释器，没有虚拟环境，也没有依赖抽奖——那这个工具就是为这种工作方式设计的。只要你的提取任务不再只是“简单地抓几个字段”，回调模型的价值就会显现出来：OnHTML 负责结构化提取，OnResponse 处理原始负载，OnError 捕捉那些否则你可能完全看不到的失败。对于静态页面或 API 驱动、而且需要按计划通过 CI 运行的目标，它是一个很稳、很省心的选择。
如果你的目标依赖 JavaScript，那就直接跳过，或者至少再搭配另一个工具。Colly 在我测试的每一个客户端渲染页面上都返回了 0，而且这正是它的设计，不是你可以切换的设置。如果你的团队根本不碰 Go，也不想为了抓几个网站就搭一套工具链，那也别选它——语言层面的投入是真实存在的，而且需要你自己维护。如果你希望拿到的是结构化数据，而不是自己写代码去解析，那么 Colly 的回调机制会把这份工作完全留给你。
替代方案——托管式 AI 抓取 API 适合放在哪
Colly 是一个免费、开源、可自行编译运行的库。你自己掌控 Go 代码、回调、抓取逻辑以及运行它的机器；回报是你不需要为每次请求付费，并且整个流程都留在内部。对于 Go 团队来说，这是一个很合理的答案，而单二进制部署也确实很舒服。
但它停下来的两个地方，也正是最值得和别的方案比较的地方。第一是 JavaScript——Colly 不会渲染 JS，所以任何客户端生成的内容都不在能力范围内，除非你自己再加一个浏览器。第二是结构化输出——Colly 只给你回调，干净结果要靠你自己的代码去整理。托管式 AI 抓取 API 对这两点的处理方式就不同。Thunderbit 的开发者栈可以处理 JS 渲染，并在服务端返回结构化数据。POST /distill 可以把网页转换成干净、适合 LLM 使用的 Markdown，并且动态内容和反爬处理都帮你做好。POST /extract 则可以根据你定义的 JSON Schema 返回结构化 JSON，遇到需要时还能把 renderMode 调到完整浏览器渲染。Thunderbit 还提供了一个面向 AI 智能体和编码助手的 MCP 服务器——thunderbit_suggest_fields 是免费的，所以你可以在真正开始前先看看页面能暴露什么字段——另外还有一个命令行工具，你可以通过 npx @thunderbit/thunderbit-cli 在终端、CI 和定时任务里运行。
这不是“谁更好，谁更差”的问题，而是“工作放在哪里”的问题。用 Colly 时，渲染（没有）、解析和维护都留在你自己的编译后二进制里，每次调用不花钱，但网站一变样你就得自己去维护。用托管 API 时，你把 JS 渲染、反爬和结构化输出都交给对方，代价是为这种省心按次付费。对于小型、原生 Go、由 HTML 或 JSON 驱动、而且你愿意自己维护的目标，Colly 的控制力和速度都足够强。对于重度 JavaScript 页面，或者你只是想直接收到符合 schema 的 JSON，而不想再写一个回调，那托管方案更合适。如果你想看更完整的版图，可以参考 最佳网页抓取工具 和 最佳网页抓取 GitHub 项目 这两篇盘点，看看像 Colly 这样的库在浏览器型和托管型方案旁边处于什么位置。
结论
要不要用 Colly？要——如果你写 Go，而且你的目标是高速抓 HTML 或 JSON，它确实配得上“快爬虫”的名声，而且现在这个名声后面有了数字支撑。静态提取召回率满分。通过 OnResponse 干净处理 JSON。500 状态正确进入 OnError，没有莫名其妙消失。深度为 2 的抓取到达了 17 个页面。所有这些都被编译进一个没有运行时依赖的静态二进制里，这几乎是这个类别里最友好的部署方式。
但也要如实看待它的边界。它不会渲染 JavaScript——我这次测试里每一个客户端页面都返回 0，而且这是永久性的，不是你漏配了什么参数。它需要 Go 工具链，所以非 Go 团队要先付环境成本。你安装的模块版本（v2.3.0）比最新 GitHub tag（v2.2.0）更前，所以页面版本不一致时别慌。并且这里说的“快”，指的是我实际测到的提取路径，而不是我没跑过的吞吐基准。在这些边界之内，Colly 是一个快速、可靠、真正可以部署的 Go 爬虫——只要你不再要求它运行 JavaScript，它就确实名副其实。
试用 Thunderbit 进行网页数据提取 Get Started Free
常见问题
Colly 真的快吗，有没有具体数字支持？ 如果从我测到的核心路径来看，它确实很快：编译后的 Go、静态提取满召回（12/12 个目录商品）、JSON 处理干净，以及一个深度为 2 的抓取跑到了 17 个页面——全部来自一个静态二进制文件。不过我没有拿它和 Scrapy 做吞吐量基准，所以这里的“快”应该理解为我测到的提取表现，而不是正面对比的速度分数。
Colly 能抓取 JavaScript 渲染的页面吗？ 不能。Colly 是一个 HTTP 爬虫——它会下载并解析 HTML，但不会启动浏览器。JavaScript 渲染测试页面返回了 0 个卡片，公开的 Quotes JS 页面也同样返回 0。对于客户端生成的内容，你需要给 Colly 配一个渲染器，或者改用自带浏览器渲染的工具。
使用 Colly 需要懂 Go 吗？
需要。Colly 是 Go 库，不是独立 CLI——你要导入它、注册回调（OnHTML、OnResponse、OnError），然后编译。我测试的机器上原本没有 Go，所以首先要安装工具链（1.26.5）。如果你的团队本来就不在 Go 生态里，那个环境搭建就是最真实的前置成本。
为什么我安装的版本和 Colly 的最新 GitHub release 对不上？
因为 Go module 和 GitHub release tag 已经分叉了。Go proxy 上最新的模块是 v2.3.0（2025 年 12 月），而 GitHub 上最新的 tag release 是 v2.2.0（2025 年 3 月）。我测试的是 v2.3.0。这只是 modules 和 tags 不一致造成的现象，不代表安装出错。
Colly 可以免费用于商业用途吗？ 可以，它采用 Apache-2.0 许可证，属于宽松且对商业友好的许可。当然，在基于它开发之前，最好还是到 repo 上确认一下当前许可证。
