网络爬虫这个词，听起来就有种“在互联网里淘金”的感觉。但淘金也得讲规矩，否则就不是淘金，而是抢劫了。我在用 Python 写爬虫的时候，最深的体会就是：爬虫技术本身没有善恶，但使用技术的人必须给自己立规矩。这也是我在学习《Python网络爬虫与信息提取》第一周“网络爬虫之规则”时，最受触动的一点。
这篇笔记想重点聊聊“盗亦有道”——爬虫领域的道，也就是 robots 协议和爬虫伦理。很多初学者上来就写 requests.get()，拿到 HTML 就解析，从不关心网站愿不愿意让你爬。等你真遇到 403、被封 IP 的时候，才明白“道”的重要性。我不会讲太多大道理，就把我看过、用过、踩过坑的经验整理出来，希望能帮你少走弯路。
1. 网络爬虫的“盗亦有道”：为什么说 robots 协议是底线规则
互联网像一个巨型图书馆，robots 协议就是图书馆门口贴着的那张“读者须知”。它不强制你遵守，但遵守它是一个合格爬虫工程师的基本素养。我在实际项目里遇到过不少同行，觉得 robots.txt 只是摆设，结果自己的爬虫被网站反爬系统盯上，轻则请求被限流，重则 IP 被拉黑，甚至收到法务函。
1.1 robots 协议到底是什么
robots 协议，全称是“网络爬虫排除标准”（Robots Exclusion Protocol），它通过一个放在网站根目录下的 robots.txt 文件，告诉所有爬虫：哪些路径你可以访问，哪些路径你不能访问。
比如某电商平台的 robots.txt 内容大致是这样的：
User-agent: * Disallow: /cart Disallow: /checkout Allow: /product这个文件的意思很直白：对所有爬虫（* 是通配符）说，购物车页面和结算页面你别碰，但商品详情页欢迎来爬。这个文件是网站管理员想和爬虫们“对话”的唯一官方渠道。
注意：robots 协议不是强制性的法律条款，在 HTTP 层面它没有任何约束力。它更像是一种君子协定——我尊重你的规则，你提供给我数据。
我个人的看法是：遵守 robots 协议，不是因为你怕网站，而是因为你要做长期主义者。短期的数据获取快感，抵不过 IP 被封的代价，也抵不过行业口碑的损失。
1.2 爬虫可能带来的三个“真实伤害”
很多人觉得爬虫无非就是访问网页，能有什么伤害？我从这个角度帮你拆解一下，你就明白为什么 robots 协议是种保护了：
第一个伤害是流量压力。一次性请求几万次页面，会给小型网站的服务器带来巨大的压力。这就好比你去一家小饭馆，一个人点了二百道菜，后厨直接瘫痪，其他真正来吃饭的顾客全被你连累了。
第二个伤害是数据安全。有些路径看似无害，但背后关联的是用户隐私。比如某些网站的用户中心路径、订单详情路径，你爬过来的数据一旦泄露，涉及的法律风险就完全超出技术范畴了。
第三个伤害是版权问题。网站的内容是别人投入人力物力创造的，未经授权批量复制传播，就涉及内容侵权。robots 协议某种程度上也在帮你规避这种风险——凡是网站不想让你索引的内容，你绕开它，就是在保护自己。
这三重伤害里，流量压力是技术性的，数据安全是法律性的，版权问题是商业性的。无论哪个层面，都值得你在发起第一次请求前停下来想一想。
2. 拆解 robots.txt 的规则语法：User-agent、Disallow 与 Allow 字段
刚开始接触 robots.txt 的人，看到满屏英文总会有点头大。其实它的语法结构超级简单，核心就是三个字段：User-agent、Disallow 和 Allow。我把常见的组合方式整理成了一张表，先整体看一眼：
| 字段 | 作用 | 示例 | 解释 |
|---|---|---|---|
| User-agent | 指定爬虫类型 | User-agent: Baiduspider | 只对百度爬虫生效 |
| User-agent | 指定所有爬虫 | User-agent: * | 对所有爬虫生效 |
| Disallow | 禁止访问的路径 | Disallow: /admin | 拒绝访问 /admin 路径 |
| Disallow | 允许访问全部（特殊情况） | Disallow: | 空值表示不限制 |
| Allow | 允许访问的路径 | Allow: /public | 允许访问 /public 路径 |
| Sitemap | 站点地图地址 | Sitemap: https://example.com/sitemap.xml | 告诉爬虫去哪里找最新链接 |
2.1 User-agent 字段的匹配优先级规则
User-agent 字段的匹配规则是自顶向下的。robots.txt 文件里会从上到下写很多组规则，爬虫在读取时，必须找到与自己 UA 名称最匹配的那一段，然后只看那段规则，其余的不看。
举个例子，假设一个站点的 robots.txt 是这样写的：
User-agent: * Disallow: / User-agent: Baiduspider Allow: /这个文件先说“所有爬虫都禁止访问”，然后又单独说“百度的爬虫可以访问全站”。如果你用 Python 的 requests 库去爬，默认 UA 是类似python-requests/2.31.0，你匹配的是第一段规则，也就是全站禁止。但如果你把 UA 改成Baiduspider，你就匹配上了第二段规则，全站畅通无阻。
这一点是很容易被忽略的细节。很多初学者写爬虫时，Response 返回 403，第一反应是加 headers 里的 User-Agent，但加的却是浏览器 UA，而网站 robots.txt 对浏览器 UA 可能恰好是 Disallow 状态。当然，正常的浏览器访问不会去读 robots.txt，但你的爬虫请求如果被反爬系统识别为脚本，它就会根据你的 UA 模拟查 robots.txt 的规则来决定怎么应对。
2.2 Disallow 和 Allow 的通配符与结尾斜杠
Disallow 的值是路径的前缀匹配。理解通配符是理解 robots 规则的关键：
$表示“匹配到行尾”。*表示“匹配任意字符序列”。
举几个实际例子：
Disallow: /private这段代码表示：凡是路径以/private开头的，比如/private/data、/privatepage，都禁止爬取。注意，/privatepage也会被禁止，因为前缀匹配不是“路径段匹配”。
Allow: /private/public这段代码如果放在上面的Disallow: /private后面，就表示网站在禁止 /private 之后，单独放行了/private/public这个子路径。
还有一个关键细节是结尾斜杠：
Disallow: /private/这个写法只禁止/private/目录本身及其子路径，而/privatepage不受影响。所以规则越具体，误伤范围越小。我在写 robots 解析工具时，经常看到新手把 Disallow 值抄错，多一个少一个斜杠，整个行为就完全变了。
2.3 通配符组合的实战模拟
来看一个稍微综合的场景，加深理解：
User-agent: * Disallow: /*.php$ Allow: /index.php这个组合的意思是：所有爬虫禁止访问以.php结尾的 URL，但index.php特例放行。这里/*.php$里的*匹配任意前缀，$固定结尾，所以login.php、admin.php都在禁止名单里，唯独index.php被后面的 Allow 规则豁免。
在实际的爬虫代码里，我自己写过一个函数来本地模拟这种匹配，核心逻辑就是“先全部匹配 Disallow，再逐个用 Allow 覆盖”。不要小看这个顺序，大多数开源工具也都是这样处理的。理解了这个逻辑，你就掌握了 robots 协议最核心的运算方式。
3. Python 环境下识别 robots 协议：两个必会的处理办法
光会读规则不够，得能在 Python 代码里自动解析并执行这些规则。我推荐两款方式：标准库自带的robotparser模块，以及自己动手实现匹配逻辑。前者适合快速开发，后者适合深度定制。
3.1 用自带的 urllib.robotparser 快速接入
Python 标准库里的urllib.robotparser提供了现成的模块，它可以把 robots.txt 的读取、解析、匹配一次性完成。下面是完整可运行的示例：
from urllib.robotparser import RobotFileParser from urllib.request import urlopen rp = RobotFileParser() rp.set_url("https://example.com/robots.txt") rp.read() # 判断某个 UA 是否允许访问某个路径 can_fetch = rp.can_fetch("my-spider", "https://example.com/product/123") print("允许爬取:", can_fetch)这段代码做三件事：设置 robots.txt 的 URL、读取内容、判断指定 UA 能否抓取指定链接。can_fetch返回布尔值，如果你拿到True，说明协议层面是允许的；False就千万别硬来。
我在实际项目中通常会把can_fetch封装成一个装饰器，放在所有爬虫函数的入口处：
def robots_check(func): def wrapper(url, *args, **kwargs): rp = RobotFileParser() rp.set_url("https://example.com/robots.txt") rp.read() if not rp.can_fetch("my-spider", url): print(f"Blocked by robots.txt: {url}") return None return func(url, *args, **kwargs) return wrapper @robots_check def fetch_page(url): # 爬取逻辑 pass这样每个爬虫函数在请求前都会过一道 robots 协议的检查，从架构层面就把“盗亦有道”立住了。
3.2 自己动手实现匹配逻辑：不依赖标准库的方案
有时候网站 robots.txt 格式不规范，robotparser解析报错，你就得自己实现。另一个自己动手的理由是：为了真正理解匹配原理，而不是只会调库。
我实现过一个简化版：
class SimpleRobots: def __init__(self, text): self.rules = [] self._parse(text) def _parse(self, text): current_ua = None for line in text.splitlines(): line = line.strip() if not line or line.startswith("#"): continue if line.lower().startswith("user-agent"): current_ua = line.split(":", 1)[1].strip().lower() elif line.lower().startswith("disallow"): path = line.split(":", 1)[1].strip() self.rules.append((current_ua or "*", "disallow", path)) elif line.lower().startswith("allow"): path = line.split(":", 1)[1].strip() self.rules.append((current_ua or "*", "allow", path)) def can_fetch(self, ua, url): path = url.split("://", 1)[-1] if "/" in path: path = path.split("/", 1)[1] access = "allow" for rule_ua, action, rule_path in self.rules: if ua.lower() != rule_ua and rule_ua != "*": continue if path.startswith(rule_path): access = "allow" if action == "allow" else "disallow" return access == "allow"这个简化版还原了“按顺序匹配、Allow 覆盖 Disallow”的核心思想。拿真实网站的 robots.txt 测一下，大部分情况都能得到正确结果。我不推荐在生产环境完全替代标准库，但作为学习工具，它非常有价值——你只有亲手写过一遍，才算真正掌握了规则。
3.3 结合 requests 库完成一次“合规请求”
有了 robots 检查，再配合 requests 库，就能完成一次完整的合规爬取流程。我通常这样组织代码：
import requests from urllib.robotparser import RobotFileParser base_url = "https://example.com" rp = RobotFileParser() rp.set_url(f"{base_url}/robots.txt") rp.read() target_url = "https://example.com/products?page=1" if rp.can_fetch("learning-spider", target_url): headers = {"User-Agent": "learning-spider/1.0"} resp = requests.get(target_url, headers=headers, timeout=5) if resp.status_code == 200: html = resp.text # 后续解析逻辑 else: print("该 URL 被 robots 协议禁止，放弃爬取")这里有几个细节值得说明：
第一，UA 要诚实。不要伪装成浏览器。伪装浏览器访问，而行为却像爬虫，反而更容易触发反爬机制。用一个说明身份的 UA，比如learning-spider/1.0，很多站点不会太为难你。
第二，超时必须设。网络请求不加 timeout，遇到响应慢的服务器，你的爬虫会挂在那里等很久，拖垮的是自己的效率。timeout=5是基本操作。
第三，状态码要判断。不要只看“返回了内容就解析”，200 和 403 的页面结构完全不同，先判断状态码再进入解析逻辑，能避免大量无效代码。
4. 爬虫的身份自觉与“行规”细节：UA 伪装、频率控制、异常处理
除了 robots 协议，爬虫圈子还有一些默认的行规。这些规矩不会写在 robots.txt 里，但它们是判断一个爬虫“专不专业”“守不守道”的重要指标。都是实际操作中一点一滴积累出来的经验，值得好好看看。
4.1 爬虫的三种身份：善意爬虫、中立爬虫与恶意爬虫
我习惯把爬虫分三类：
| 类型 | 特征 | 典型例子 | 网站态度 |
|---|---|---|---|
| 善意爬虫 | 遵守 robots、低频抓取、自带 UA 标识 | 搜索引擎爬虫（如某搜索引擎的 spider） | 欢迎 |
| 中立爬虫 | 遵守 robots，但抓取频率较高 | 数据采集工具、行业监控脚本 | 容忍，但会限流 |
| 恶意爬虫 | 无视 robots、高频请求、伪装身份 | 撞库脚本、批量薅羊毛工具 | 封禁并追责 |
做爬虫开发，默认要当“善意爬虫”，这是行业共识。搜索引擎的爬虫为什么被欢迎？因为它在替网站做推广、引流量，双方都有收益。你的爬虫如果能给网站带来价值（比如做索引、做收录），网站自然欢迎；如果只是单向索取，就要小心处理频率和流量。
4.2 UA 伪装的两面性：为什么我不建议无脑伪装成浏览器
很多教程都让你把 UA 改成 Chrome 的样子，说这样可以“骗过”反爬系统。但这里面有一个逻辑漏洞：
robots 协议里的 User-agent 字段，代理的是“爬虫身份”。如果你把 UA 改成浏览器，robots 协议就无法正确适配规则。
举个例子，某个网站可能对googlebot完全开放，但对Mozilla/5.0（浏览器）设置了很多限制。你伪装成浏览器去访问，反而拿到了更严格的反爬策略匹配。
我的建议是：使用自己独特的爬虫 UA。例如my-project-spider/0.1 (contact: email@example.com)。这种 UA 明确告诉服务器“我是爬虫，我有身份，我遵守规则”。很多大站在遇到这种 UA 时，反而会放行，因为它们知道这是一个有道德约束的爬虫。
但如果你的目标网站确实对爬虫 UA 直接封禁，那说明这个网站根本不想让你爬，这时你应该尊重它的意愿，而不是想办法绕过。做一个有底线的工程，比做一个“技术流”的爬虫更难，但更值得。
4.3 抓取频率控制：用睡眠和随机延时节流
爬虫最惹人烦的行为就是“高频密集抓取”。一个负责任的爬虫该学会“克制”。我在代码里实现最简单也最实用的节流逻辑：
import time import random def polite_sleep(): # 核心是随机延时，避免触发行为分析 delay = random.uniform(1, 3) time.sleep(delay) # 爬取循环中调用 for page_num in range(1, 100): url = f"https://example.com/products?page={page_num}" # 先检查 robots 协议 if rp.can_fetch("my-spider", url): resp = fetch_page(url) parse(resp) else: continue polite_sleep()random.uniform(1, 3)的意思是每次请求之间随机休息 1 到 3 秒。为什么要随机而不是固定 2 秒？因为固定间隔容易被服务器的访问日志识别出规律。真实用户的访问间隔是有波动的，模拟这种波动可以让你的爬虫更不引人注意。
注意：延时不是万能的。如果目标是站点有明确 QPS 限制，你设再长的随机延时也可能被封。最稳妥的办法是观察服务器的响应头，如果出现
Retry-After或429状态码，立即停止抓取。
4.4 异常处理中的“礼貌三原则”
写爬虫不可能一路顺风，连接超时、DNS 解析失败、响应内容不完整，各种异常层出不穷。在异常处理中，我总结出爬虫的“礼貌三原则”：
原则一：不要立刻重试。收到 503 或超时，立刻重试大概率会再次失败，而且加重服务器负担。休息 30 秒再试，是更礼貌的做法。
原则二：记录日志。把每次请求的状态码、耗时、异常信息写入日志。很多新手忽略日志，出了问题两眼一抹黑。好的日志是爬虫的“黑匣子”。
原则三：预留退路。一个目标失效时，备选源顶上。不要把鸡蛋放在一个篮子里，抓取任务尤其如此。我手里同时维护三个数据源，每个源的 robots 规则不同，通过抽象层统一切换。
class PolitenessManager: def __init__(self, source_url): self.rp = RobotFileParser() self.rp.set_url(f"{source_url}/robots.txt") self.rp.read() self.session = requests.Session() self.session.headers.update({"User-Agent": "polite-spider/1.0"}) def fetch(self, url, retries=2): if not self.rp.can_fetch("polite-spider", url): return None for attempt in range(retries): try: resp = self.session.get(url, timeout=5) if resp.status_code == 200: return resp.text elif resp.status_code == 429: time.sleep(30) continue else: return None except requests.exceptions.Timeout: time.sleep(30) continue return None这个小类封装了 robots 检查、UA 设置、超时、429 处理、重试策略。如果你的爬虫连这个级别的“礼貌”都做不到，那就别抱怨网站封你。
5. 实战中“道”的边界：那些容易被忽略的软性规则
到这里，基本的 robots 协议解析和请求策略都已经覆盖了。但“盗亦有道”还有一层容易被忽略的维度，我把它单独拿出来讲，因为它直接关系你的爬虫项目能不能走远。
5.1 robots 协议与实际反爬策略的错位
机器人协议和反爬系统是两套体系。robots 协议告诉你应该访问哪些路径，反爬系统则是网站应对真实攻击的防御工事。二者常常错位。
错位一：协议允许但反爬拦截。有些路径 robots.txt 明明放行，但你用代码访问还是会 403。原因可能是网站对所有非浏览器客户端默认拦截，也可能是你所在 IP 段的访问频率过高被标记。
错位二：协议禁止但反爬不严。某些后台管理地址 robots 里写着 Disallow，但服务器并没有做防护。很多爬虫初学者看到这里会想“那我不是可以钻空子”？我劝你不要：真正的安全漏洞管理是网站自己的事，你不该利用别人的疏忽获取数据。这就是“道”的底线。
5.2 “软性墙”和“硬性墙”：识别网站传达的间接信号
除了 robots.txt 这种明文规则，网站还会通过其他方式传达“请勿爬取”的信号。我把它们分成两类：
硬性墙是明确的技术手段：登录墙、验证码、IP 封禁、数据加密。遇到硬性墙，第一反应应该是“我是不是越界了”，而不是“怎么绕过它”。
软性墙是间接信号：页面加载速度突然变得极慢、数据接口响应异常、某些页面突然出现乱码诱导数据。这些可能是网站手工放出的假数据，也可能是运维正在调整。遇到这些信号，成熟的爬虫开发者会选择暂停，而不是加大抓取力度。
我在一次爬取公开论文列表时，发现某天返回的数据里混有“此内容仅供授权用户查看”的字样，但状态码是 200。当时我就明白——网站已经意识到有人在抓取，并且开始调整返回策略。我没有选择破解“软性墙”，而是转而通过官方 API 获取数据。虽然对方 API 有调用次数限制，但至少我保住了 IP 和数据源的长期可访问性。
5.3 当 robots.txt 不存在时怎么办
很多小型个人网站根本没有 robots.txt。这既不代表“欢迎爬取”，也不代表“禁止爬取”。我的处理原则是这样的：
- 如果网站有 API，优先用官方 API。
- 如果没有 API，看对方的网站规模和技术栈。明显是个人博客，就降低抓取频率，克制到一个非常保守的水平（比如每 10 秒一个请求）。
- 尽量只抓取必须的数据，不做全站镜像。
- 在代码注释或项目 README 里记录抓取来源和时间，方便自己追溯。
一句话：没有 robots.txt，你要给自己写一份“道德 robots.txt”。这种自律在短期内看不出好处，但长期会让你在整个数据生态里保持一个干净的身份。一旦你的爬虫需要和网站协商数据合作，你的历史记录经得起审视，这就是无声的优势。
5.4 关于 robots 协议的二三争议：它到底有没有“法律效力”
每次聊 robots，都会有人问“它到底有没有法律强制力？我违反了会被抓吗？”这个问题要分两面说。
从技术层面看，它只是文本文件，不构成任何加密、鉴权、防火墙机制。访问 Disallow 的路径和访问 Allow 的路径，在 HTTP 请求层面没有任何区别——服务器照样会响应，请求照样能成功。
但从行业和法律实践层面看，违反 robots 协议的行为已经在多起判例中被作为判断爬虫是否“恶意”的重要依据。注意，我不是在引用具体案例，而是说一个趋势：当纠纷发生时，robots.txt 的内容会成为评判爬虫行为是否超出授权的参考标准之一。只要你绕过了 Disallow 区域去获取数据，哪怕技术上毫无难度，你的行为也可能被认定为违反网站的访问意愿。
所以我的建议非常明确：把 robots.txt 当作网站对你单方面声明“这是我的地盘”的那条线。越过了，你赢了技术，输了道理。
6. 从“盗亦有道”到爬虫开发者的自我修养
写到这里，第一周“网络爬虫之规则”的笔记也接近尾声。回头看看，这周的重点表面上是规则，本质上是建立爬虫开发者的自我修养。技术学得多快都不难，难的是知道什么时候不该用。
我在动手写爬虫前，有一个固定流程，现在分享给你：
- 先看目标网站有没有明确的 API 官方通道，有就优先用。
- 再看 robots.txt，理解网站的边界声明。
- 然后小批量测试（比如 5 个请求），观察响应状态和速度。
- 确认没问题后，才正式写抓取策略，并始终像上面介绍的那样设置 UA、频率控制、超时和重试。
- 最后，在项目里留一份 README，注释清楚数据来源、抓取规则和合规依据。
这个过程每次执行下来，虽然会多花几十分钟，但能避免后面好几天的返工。这也是我反复在团队里强调的：爬虫项目的真正成本，从来不是抓取难度，而是合规成本。你前期不计较，后期它一定加倍跟你算账。
如果这篇笔记对你有帮助，希望你也把“盗亦有道”放在心上。赚钱当然重要，但做一个长期运行的爬虫项目，一个能在阳光下面见人的项目，更让我安心。这也是我现在愿意花大量篇幅分享 robots 协议的原因——在我看来，它不仅是技术规范，更是爬虫开发者给自己立的“道”。
