事情要从一堂创新创业课说起。

课上的数据分析作业需要一组抖音带货达人的样本数据——什么品类热门、哪些达人在带货、带货视频的发布频率如何。听起来不难，但真动手的时候才发现：网上找不到现成的工具。

有些收费软件一个月几百块，学生负担不起；有些开源项目已经停更两三年，接口早就变了。我当时就想：不如自己写一个。

最初的想法很简单。用 requests 发 HTTP 请求，搜一个关键词，拉下来几十条视频，把作者信息提取出来，导出到 Excel。代码不到 200 行，用的同步请求，搜一次关键词大概要等两三分钟。能用，但有个致命问题——太慢了。如果我要分析 5 个品类、每个品类拉 200 条视频，光是搜索就要十几分钟，再加上分析每个达人的主页作品，整个流程跑完差不多半小时。而且同步请求期间程序处于假死状态，什么都干不了。

第二版我决定全面转向异步。把 requests 换成 httpx 的异步客户端，用 asyncio 管理并发——搜索请求可以同时发出多个，达人主页扫描也是并发执行。改造成果立竿见影：同样的数据量，时间从半小时压缩到了 2-3 分钟。

但新问题出现了——太快了。抖音的限流机制会在短时间内大量请求时返回 HTTP 444（无响应），或者直接返回空数据。一味追求速度反而得不偿失。

这就引出了我最满意的设计——三档速度模式。不是在代码里硬编码一个固定的请求间隔，而是设计了安全、快速、极速三档，每档的搜索间隔、达人间隔、作品间隔都不同。安全模式间隔最长、稳定性优先，适合长时间无人值守；快速模式平衡速度和风险；极速模式间隔最短，适合少量样本的快速验证。用户可以根据自己的网络环境和风险承受能力自由选择。这个设计后来成了整个项目最受欢迎的功能之一。

纯命令行工具对会写代码的人来说没问题，但同组的其他同学连 Python 都没装。所以我用 Tkinter 写了一个桌面 GUI——搜索关键词、设置参数、查看进度、导出 Excel，全部可视化操作。这也意味着需要处理 Cookie 获取的问题：抖音的 Web 端搜索需要登录态，我搞了四种 Cookie 获取方式——浏览器自动提取（Playwright）、rookiepy 提取、CDP 调试端口提取、剪贴板 cURL 粘贴。四种方式覆盖了绝大多数使用场景。

东西做完之后，同组同学拿去跑了三天，拉了几千条数据，做了完整的带货品类分析报告。自己写的工具被别人真正用起来，那种感觉比任何技术指标都来得实在。

这个项目也让我更坚定了一个认知：工具不需要完美，但需要解决真问题。不是每个人都关心 httpx 的并发实现，但他们关心”能不能在 5 分钟内拿到我想要的数据”。技术服务于需求，而不是反过来。

项目开源在 GitHub 上：douyin-crawler