robots.txt文件仅声明爬取许可（Allow/Disallow路径），不定义限流参数；合规需先解析其规则，再结合Crawl-delay、User-agent匹配及分布式Redis限流实现动态请求节制。
Robots协议不是限流指令，而是爬取许可声明
直接说结论：robots.txt 文件本身不定义请求频率、并发数或等待时间，它只通过 Allow 和 Disallow 指令说明哪些路径能爬、哪些不能爬。所谓“遵守 Robots 协议”不等于“按某个固定 QPS 限流”，而是：先读取并尊重其规则，再在此基础上自行设计合理、低干扰的请求节奏。
很多新手误以为只要加个 time.sleep(1) 就算合规，其实跳过 robots.txt 解析、无视 Crawl-delay（非标准但常见）、对 User-agent 不做匹配，都属于事实上的违规。
实操建议：
- 每次启动爬虫前，必须用
requests.get("https://example.com/robots.txt")获取并解析，不要硬编码缓存 - 注意
Crawl-delay是秒级浮点数（如Crawl-delay: 2.5），需转换为time.sleep()的实际参数 - 不同
User-agent可能对应不同规则，分布式环境下所有节点必须使用统一且声明过的User-agent字符串（如"MyBot/1.0 (+https://mybot.example)"） - 若目标站返回 403 或 404 的
robots.txt，按保守策略默认禁止全部路径（除非有明确白名单授权）
分布式环境下如何同步限流状态？
单机用 time.sleep() 或 asyncio.sleep() 就够了，但多进程、多机器时，各节点无法感知彼此请求节奏，容易集体触发反爬或超频。核心矛盾是：限流窗口（如每 10 秒最多 5 次）必须跨节点共享计数和时间戳。
立即学习“Python免费学习笔记（深入）”；
推荐用 Redis 实现原子限流器，避免引入 ZooKeeper 或 etcd 等重依赖：
- 用
INCR+EXPIRE组合实现滑动窗口计数（例如 key 为flood:example.com:20240520_14，TTL 设为 60 秒） - 关键逻辑必须包裹在 Lua 脚本中执行，防止竞态（Redis 官方推荐方式），示例脚本片段：
if redis.call("INCR", KEYS[1]) == 1 then redis.call("EXPIRE", KEYS[1], ARGV[1]) end return redis.call("GET", KEYS[1]) - 每个请求前调用该脚本，检查返回值是否 ≤ 允许最大请求数；超限则
sleep后重试，而非直接报错 - 注意 Redis 连接池要配置
max_connections，避免限流器自身成为瓶颈
requests + aiohttp 怎么适配分布式限流？
同步库（requests）和异步库（aiohttp）的限流接入点完全不同，不能混用同一套 sleep 逻辑。
对 requests：
- 封装一个带阻塞等待的会话类，每次调用
.get()前先查 Redis 计数器，再time.sleep() - 绝对不要在循环里反复
requests.get()后再判断限流——此时请求已发出
对 aiohttp：
- 用
await asyncio.sleep()替代time.sleep()，否则会阻塞整个事件循环 - 在
aiohttp.ClientSession的__aenter__阶段预热 Redis 连接，避免每次请求都新建连接 - 如果用
asyncio.gather()并发大量请求，需配合asyncio.Semaphore控制并发数，再叠加 Redis 计数器控频，二者缺一不可
被反爬拦截时，限流策略要不要自动退避？
要，而且必须是自适应的。固定延时（如永远等 2 秒）在面对动态反爬（如验证码、JS 挑战、IP 封禁）时毫无意义。
实操上可结合响应特征动态调整：
- 遇到
429 Too Many Requests或503 Service Unavailable，把当前域名的Crawl-delay临时翻倍，并写入本地缓存（如 SQLite 表），持续 10 分钟 - 检测到 HTML 中含
cloudflare、turnstile、recaptcha等关键词，立即暂停该 IP 对该域名的所有请求至少 30 分钟 - 所有退避动作必须记录日志（含时间、域名、退避原因、新 delay 值），否则下次重启就丢失上下文
- 注意：退避策略不能替代 Robots 协议解析，只是运行时兜底；前者是法律/伦理前提，后者是工程容错手段
真正难的不是写限流代码，而是让所有节点对同一个域名的访问节奏达成共识，同时不因某台机器故障拖垮全局。Redis 的可用性、Lua 脚本的正确性、User-agent 的一致性，这三个点漏掉任何一个，所谓的“分布式合规”就只是幻觉。
