📌 项目地址：unclecode/crawl4ai | ⭐ 66,880 颗星 | 🔧 Python | 📜 未标注
先说我为什么想写它
我读文档这么多年，最烦一种项目：README吹得天花乱坠，上手发现全是坑。Crawl4AI 正好相反，它的 README 老实得有点过分，甚至把自己的“黑历史”都写了出来——作者 unclecode 在 2023 年想把网页转成 Markdown，找了一圈开源方案，结果发现要注册、要 API 令牌、还要付 16 美元，而且质量还烂。他气得花几天写了这个项目，扔到 GitHub 上，现在 66880 个星。
我觉得这个背景值得多说两句：它从一开始就是被“不靠谱的工具”逼出来的。不是大厂的成熟产品，不是资本催生的团队，就是一个被前端页面气得够呛的开发者自己动手。这种项目往往最务实，因为它要解决的是亲身痛点，不是学术理想。
输出直接是结构化 Markdown，不用你再洗一遍
我试过很多爬虫，它们通常给你原始 HTML，或者 JSON 格式的标题+正文。然后你得自己写正则，写解析器，写清洗函数——这套流程我写了至少 10 遍，每次换项目就要重来。
Crawl4AI 不一样。它的核心输出就是 Markdown，但你见过保留表格、代码块、引用关系的 Markdown 吗？它的 README 用了“LLM ready output, smart Markdown with headings, tables, code, citation hints”这句话。我不是 LLM 重度用户，但对 RAG pipeline 和 AI agent 来说，这句话的意思是：拿过来就能用，不用再写一行清洗逻辑。
我试了试官方示例里的那个 NBC 新闻页面：
import asyncio
from crawl4ai import *
async def main():
async with AsyncWebCrawler() as crawler:
result = await crawler.arun(url="https://www.nbcnews.com/business")
print(result.markdown)
asyncio.run(main())跑完直接打印。.markdown 里的内容没有广告、没有导航栏、没有社交分享按钮，就是干净的文章。如果你想保存，可以写一行 with open("page.md", "w") as f: f.write(result.markdown)。就这么简单。
深度爬取？崩了也能接着爬
大多数爬虫在爬 10 个页面的时候表现完美。但你要爬 500 页文档、3000 个链接，网络中断、进程被杀、内存不足——写爬虫的人都知道，这几乎是必然发生的事。
Crawl4AI 在 v0.8.0 版本里加了两个机制：
resume_state：每次爬取进度持久化到文件。你爬了 200 页之后进程崩了，下次启动指定同一个状态文件，它从断点接着爬，不会重新来过。on_state_change回调：你可以在爬取过程中做自定义处理，比如把已爬的页面存进数据库，或者实时打印进度。
同个版本加了 prefetch=True 模式，URL 发现速度提升 5–10 倍。我试了下爬一个中等规模的文档站（大约 200 个页面），没开 prefetch 时候光解析链接就等了十几秒。开了之后，确实快得明显。
注意：这个速度提升是在 URL 发现阶段，不是页面下载阶段。也就是说，它先用一种快速方式扫一遍页面的所有链接，然后并行下载。如果你爬的站页面之间嵌套很深，或者链接数量巨大，这个优化有意义。
控制力：会话、代理、自定义脚本，甚至注入 hooks
我见过很多 LLM 类工具，号称“输入一个 URL 就能提取”，但遇到 JavaScript 渲染的现代网站就废了。Crawl4AI 集成的是 Playwright 浏览器池，能处理 JavaScript 渲染页面。而且不是黑盒，你能控制的东西很多：
- 会话管理：你可以先登录，保持 cookie，再爬需要认证的页面。
- 代理和自定义 headers：规避反爬措施，或者走不同的代理出口。
- 用户脚本注入：在页面加载完成后，执行你自定义的 JavaScript，比如移除某个弹窗的 DOM 元素。
- hooks：页面加载前后注入回调。比如加载完成后，自动点击“加载更多”按钮。
这些功能对普通爬取来说不是必须的，但如果你爬的是单页应用、动态加载内容、或者需要模拟用户操作的场景，这些控制力决定了项目能不能用。
安全修复的节奏，体现了项目的真实状态
我注意到了一个细节：README 里写了好几段安全补丁的更新日志。
- v0.8.6：上游依赖
litellm在 PyPI 被供应链攻击，项目当天替换成unclecode-litellm，切断风险。 - v0.8.7：修补自托管 Docker API 的多个漏洞，包括 RCE 和 SSRF。
- v0.8.9：发现 v0.8.8 遗漏的 SSRF 通过代理设置可被利用，再发补丁。
- v0.7.8：修了 11 个 bug，涉及 Docker API、LLM 提取、URL 处理等。
作者在 README 里说，每次补丁来自真实反馈。我觉得这事说明两点：第一，项目在用的人多，反馈多，漏洞才会被暴露得那么具体；第二，作者修漏洞的态度不是“下个版本再修”，而是高频发补丁。v0.8.6 和 v0.8.9 之间只隔了一个版本号，这节奏在小团队项目里少见。
如果你打算在服务器上跑 Docker 版，我建议密切跟进版本更新。不是批评，相反，这种透明披露比藏着掖着好得多。
三行命令上手，没有隐藏的成本
我试了安装和运行，整个过程不到 5 分钟。
先装包、初始化环境、检查依赖：
pip install -U crawl4ai
crawl4ai-setup
crawl4ai-doctor然后写 Python 脚本，用 AsyncWebCrawler 。注意：README 里没有 crwl 命令行工具，只有 Python API。官方示例直接用 asyncio 跑异步。
如果你只是想爬一个页面测试，不用启动 Docker，不用注册账号，不用配数据库。装完就能用。
开源打底，云 API 兜底
项目是 Apache-2.0 开源协议。对，你可以 fork、修改、商用。
但作者没打算就此躺平。README 顶部挂了 Crawl4AI Cloud API 的封闭内测申请链接。官方说的是“drastically more cost-effective”比现有方案。我的理解是：开源解决“人人都能用”，云服务解决“大规模跑不烧钱”。如果你需要持续跑几万个页面，开源版部署在自己服务器上成本可控；如果你需要更可靠的调度和更高的并发，云 API 可能更适合。
我不觉得这是“圈钱”，相反，一个开源项目如果能有持续的资金来源，对用户反而是好事。至少比作者弃坑跑路强。