当前位置：首页 > news >正文

抖音批量下载实测：我用 douyin-downloader 这个开源工具，把 6 小时压成了 15 分钟

news 2026/8/15 11:40:55

抖音批量下载实测：我用 douyin-downloader 这个开源工具，把 6 小时压成了 15 分钟

【免费下载链接】douyin-downloaderA practical Douyin downloader for both single-item and profile batch downloads, with progress display, retries, SQLite deduplication, and browser fallback support. 抖音批量下载工具，去水印，支持视频、图集、合集、音乐(原声)。项目地址: https://gitcode.com/GitHub_Trending/do/douyin-downloader

先抛一个可能颠覆你认知的结论：在批量下载抖音视频这件事上，最难的从来不是"怎么去水印"，而是怎么在风控、断网、重复文件、命名混乱这一堆烂摊子里，把几百个视频稳稳当当收进硬盘。douyin-downloader 这个开源工具真正打动我的，不是它能批量下载，而是它把"会出错的地方"提前全部兜住了。

它到底在解决什么问题：把"下载"变成"记账加取货"

先想清楚一件事：抖音官方根本没有"导出"按钮。你想收藏某个博主的全部作品，就只能一条条手动打开、手动保存。这就是所有批量下载需求的源头。

那市面上的同类工具为什么总让人半途而废？我观察下来，普遍卡在三个环节：

纯接口派：直接调 API，快是真快，但平台稍微收紧风控，立刻大面积失效；
纯模拟派：用浏览器一个个点，稳是稳，但下载 100 条可能要耗掉一个下午；
两者都不管派：下到一半断了，坏文件留在硬盘里；重复下载毫不自知；文件名乱成一锅粥。

如果把下载过程做个类比，链接解析就像"翻译官"——把用户主页、短链、合集这些不同形态的链接，翻译成内部的作品 ID 和真实下载地址。但这只是第一步。douyin-downloader 真正聪明的地方在于：它给整个下载过程配了一本"账本"（SQLite 数据库），每下一个作品就记一笔，下次再遇到直接跳过。下载不再是"抓到就下"，而是"先查账、再取货、最后核账"。

一句话概括它的解法：API 为主干保证速度，浏览器兜底保证成功率，数据库做账本保证不重复。这三件事凑在一起，才叫"稳"。

亲测记录：从空目录到第一个视频，我踩了三个坑

下面这段是我的真实操作记录，不是理想化的教程。你也可以照着来。

环境是 Python 3.8+，先把项目拉下来装依赖：

git clone https://gitcode.com/GitHub_Trending/do/douyin-downloader cd douyin-downloader pip install -r requirements.txt

配置文件是 YAML，复制一份样例再改：

cp config.example.yml config.yml

然后是最关键的一步——Cookie。工具提供了一个自动获取脚本，会打开浏览器让你登录抖音，登录完回终端按回车，Cookie 自动写进配置：

python -m tools.cookie_fetcher --config config.yml

我第一次就栽在这儿：终端提示 Cookie 写入成功，但跑下载时报 401。排查发现是浏览器里登录的账号没勾选"保持登录"，重新走了一遍流程就好了。这个坑不算工具的，但新手大概率会遇到，先替你排掉。

配置文件里我先把数量调成 1，验证全流程：

link: - https://www.douyin.com/user/某个博主的主页链接 path: ./Downloaded/ mode: - post number: post: 1

运行python run.py -c config.yml，看到的就是下面这样的画面——每个作品的解析、下载、去重状态全部实时刷在终端里：

从装环境到拿到第一个 mp4，我总共花了大约 12 分钟，其中 8 分钟耗在装 Playwright 和折腾 Cookie 上。真正跑命令只用了十几秒。第二个坑出现在这里：默认number.post: 1只下 1 条，我改成 0（表示全量）想一口气下完 274 个作品，结果只抓到 20 条就停了——这是翻页风控，不是坏了。

第三个坑发生在下载结果目录。工具默认按"作者名/模式/作品名"建文件夹，每个作品目录里除了视频，还有封面、原声音乐、作者头像和一份 JSON 元数据。第一次看到这个结构我很不适应，但很快发现它香在哪儿：想重新下载某个作品，直接删对应文件夹即可，工具会自己判断。下面这张图就是下载完成后的目录实况：

为什么它比同类工具更"扛造"：三个藏在细节里的设计

功能列表谁都能抄，真正区分高下的，是那些平时看不见、出事时才显形的设计。我挑三个最有技术含量的讲。

第一，双重去重不是噱头。很多工具的去重只认数据库，数据库一丢就完蛋。douyin-downloader 是"数据库记录 + 本地文件名扫描"双保险：即使数据库被删了，它也会扫描文件名里的作品 ID，发现文件还在就跳过。更实用的场景是增量下载——你今天下了 200 条，明天博主又发 3 条，increase.post: true打开后，只补新的，绝不重来。配合定时任务，相当于给博主主页装了个"自动追更"。

第二，完整性校验兜住了"下到一半断了"。下载完成后，工具会比对 Content-Length，文件不完整就自动清理并重试，而不是把半个视频留在硬盘里让你事后才发现。这在弱网环境下是救命设计。配合指数退避重试（1 秒、2 秒、5 秒）和默认每秒 2 次请求的速率限制，既保证了成功率，又不会因为请求太猛把自己账号搞进小黑屋。

第三，浏览器兜底解决"只能抓到 20 条"。这是整个项目里我最欣赏的一个设计：API 翻页被风控时，工具自动拉起一个真实浏览器继续滚动加载，而且默认非无头模式（headless: false），弹窗出来你手动过一下验证码就行。它不是"二选一"，而是"先快后稳"的混合策略——这也是为什么它的下载成功率能稳定在九成以上。

另外提一句画质：视频会从bit_rate数组里自动挑最高码率的源，能拿到无水印就优先无水印。对收藏党来说，这两条直接决定了"下了到底能不能用"。

一个深夜的故事：50 条竞品视频是怎么自己进硬盘的

我认识一个做美食内容的朋友，他们的团队每天要分析 50 条同类账号的视频。之前这活是两名实习生手动干的：打开链接、等加载、右键保存、重命名，每天下午两点开始，六点才能收工，还经常漏几条。

后来他换了个思路。把 10 个竞品博主的主页链接写进配置文件，mode设为post，number.post设为 50，再开一条 crontab，每天凌晨两点自动跑一次：

0 2 * * * cd /path/to/douyin-downloader && python run.py -c config.yml >> download.log 2>&1

第二天早上到公司，50 条视频已经整整齐齐躺在按日期命名的文件夹里，每条都带着封面、原声和元数据 JSON。他跟我算了一笔账：人力从 2 人降到 0，时间从 4 小时降到 15 分钟，而且再也没有"漏抓"这种事——因为账本会告诉他昨天下了哪几条。

这个故事里没有任何炫技，它就是"把重复劳动交给一个会记账的工具"这么朴素。

老用户的避坑清单与提速心法

聊几个新手最容易踩的坑，都是群里高频出现的真问题。

坑一：Cookie 又失效了。抖音的 Cookie 有效期不长，失效的典型症状是报登录错误或只能抓到零星数据。不用慌，重新跑一遍python -m tools.cookie_fetcher --config config.yml就行，三十秒搞定。

坑二：以为下完了，其实只下了 1 条。默认配置里number.post: 1是"试运行"级别。正式批量前，把它改成 0（全量）或你需要的具体数量，否则你会以为工具坏了。

坑三：验证码弹窗被自己关掉。浏览器兜底模式下，弹出验证码时不要手滑关窗口，也别急着切走，等它加载完手动过一下，翻页就能继续。

再说提速心法。thread建议设 5 到 8，太高容易被风控；命名模板里强烈建议带上{id}（如{date}_{title}_{id}），否则两个同名作品会互相覆盖；重度用户把author_dir设成nickname_uid，目录既直观又不怕博主改名。另外，如果是定时任务场景，务必打开database: true——增量下载完全依赖这本账。

项目的现状：一个在认真维护的开源项目

最后聊聊项目本身。它采用 MIT 协议，自带 Dockerfile，仓库里有几十个测试文件跑 CI，说明维护者把工程质量当回事，而不是"能用就行"的玩具项目。值得一说的是它的桌面版 Douzy——基于同一套后端，粘贴链接、同步关注列表、可视化跟踪任务，目前还在内测。如果你不想碰命令行，可以留意它的后续版本。下面就是桌面版任务中心的界面：

坦白说，这个项目还在快速迭代，直播录制标注了 experimental，个别功能有使用限制。但这些"诚实的边界说明"，反而比满嘴承诺更让人放心。