抓别人平台的内容，第一原则不是”快”，是”别把对方搞死，也别把自己搞死”。
这条原则写进代码之后，整个抓取流程会变得很慢。慢到你第一次用会怀疑是不是卡住了——所以最后还得专门做”等待可见”。
微博的节奏
翻页间隔 8 到 13 秒，随机。
每连续 3 页，额外停 45 到 75 秒。
失败的时候，任务内最多再等 3 分钟，然后把断点保存下来。
这不是我拍的数，是社区里被风控教育出来的经验（RSSHub 和几个微博爬虫的 issue 里都是类似量级）。微博的翻页风控按频率和深度双重判断：短时间内连续翻，几十页就触发；慢慢翻，能翻几百页。
所以「深度回溯」这个功能，文档里写着请隔 30 到 60 分钟再跑。早年内容不是一次能拉完的，得多次续跑。
打满 200 页要明确提示”更早的没拉到”。这一点比限流本身重要——如果界面显示成功，用户会以为存全了，实际上只存了一半。
X 和 Instagram 交给 gallery-dl
这两个不用自己控制节奏，gallery-dl 的配置项够用：
| 配置 | 值 | 含义 |
|---|---|---|
sleep | 1.5 – 4s | 每个请求之间 |
sleep-request | 6 – 12s | 请求间隔的另一个档位 |
sleep-429 | 60s | 遇到 429 |
ratelimit | wait: 300 | 触发速率限制时等 5 分钟 |
| 下载线程 | 2 | 上限 |
最要紧的一条：429 不要手动杀进程。
gallery-dl 收到 429 会自己退避重试。你一看日志不动就杀掉重启，等于把它已经排好的等待重置了，下次更快撞墙。看起来”重启一下更快”，实际是越来越慢。
批量任务：失败要能重来，但不能立刻重来
批量缓存几十个用户，中间挂几个是正常的。
失败自动重试，指数退避，默认最多 3 次，设置里可关。
有些错误重试有用（网络抖动、临时 5xx），有些没用（Cookie 失效、账号私密）。指数退避的作用是让前者过关，至于后者，重试三次之后失败，日志里能看见真实原因。
等待要有反馈
30 秒没有任何输出，主进程会往日志里发一条心跳，提示”可能正在限流或重试”。
这条是给用户看的，不是给机器看的。因为未知的等待比慢更难受——你不知道它是卡住了还是在老老实实地睡。
这个项目里慢的地方几乎都是刻意的。真正该优化的不是抓取速度，是让用户知道自己在等，而且等得有意义。