必须每次请求前调用urllib.robotparser.can_fetch()校验最终url，且user-agent须与robots.txt中声明完全一致；含通配符规则需手动正则回退；遵守robots.txt不豁免敏感数据爬取违法责任。
不能靠“不看robots.txt”来规避风险——不检查就是违规，不是没风险。
urllib.robotparser.can_fetch() 必须每次请求前调用
很多人把 rp.read() 放在初始化阶段就完事，之后所有 URL 都不再校验。这是典型误用。can_fetch() 不是“查一次管全场”，它对每个 URL + User-agent 组合单独判断，且结果受重定向、通配符、路径匹配逻辑影响。
- 必须在
requests.get()前调用rp.can_fetch(user_agent, final_url)，其中final_url是实际要请求的地址（注意：若存在 301/302 跳转，得用跳转后的 URL 再校验） - 不能传入带查询参数的 URL 后直接匹配——
Disallow: /api/会拒绝https://example.com/api/user?id=1，但Disallow: /api/user不会拒绝/api/user?token=xxx - 如果网站 robots.txt 用了
Allow: /api/data和Disallow: /api/这种嵌套规则，can_fetch()会按顺序匹配并取最后有效结果，你不能靠肉眼判断
User-agent 字符串必须真实可追溯
rp.can_fetch() 的行为严重依赖传入的 User-agent 字符串是否被 robots.txt 显式声明。用 "*" 或空字符串、伪造浏览器 UA（如 "Mozilla/5.0..."），很可能导致解析器 fallback 到 User-agent: * 规则，而该规则常是 Disallow: /。
- 应使用带域名和联系信息的真实标识，例如
"MyCorpBot/2.1 (+https://data.mycorp.com/bot)" - 确保该字符串与 robots.txt 中某段
User-agent:行完全一致（大小写敏感、空格一致） - 若目标站只写了
User-agent: MyCorpBot，你传"MyCorpBot/2.1"就不匹配，会被当成*处理
robots.txt 不支持通配符时需手动补正
urllib.robotparser 原生不解析 *、$ 或正则语法。像 Disallow: /api/*/profile 或 Disallow: /search?.* 这类写法，can_fetch() 会直接忽略或错误匹配。
- 遇到含
*的 Disallow 行，需额外用re.match()模拟匹配逻辑，例如：re.match(r"^/api/[^/]+/profile", path) - 查询参数（
?后内容）默认不参与can_fetch()判断，但很多网站明确禁止带特定参数的路径，此时必须自己 parse URL 并比对 - 建议封装一个
is_allowed(url, rp, user_agent)函数，内部先走rp.can_fetch()，再对 robots.txt 中含通配符的规则做正则回退校验
法律上，“遵守 robots.txt”只是起点，不是免责金牌
法院判例（如百度诉360案）已确认 robots 协议是行业公认商业道德，违反即可能构成不正当竞争；但反过来，严格遵守它也不等于自动合法——如果爬取的是手机号、身份证号等敏感信息，哪怕页面公开、robots.txt 没禁，也违反《个人信息保护法》第10条。
- robots.txt 只管“能不能爬”，不管“能不能存、能不能用”。爬到
tel:138****1234，立刻丢弃、不落盘、不进日志，否则就是违法采集 - 某些网站把核心数据放在
Disallow: /api/下，但前端 JS 拼接请求并渲染——你复现该逻辑仍属绕过限制，司法实践中已被认定为“规避技术措施” - 真正高危动作不是“没查 robots.txt”，而是“查了还硬上”，或“查了但无视 Crawl-delay、无视 Sitemap 提示的更新频率”
最容易被忽略的一点：很多开发者以为只要 can_fetch() == True 就万事大吉，却没意识到，服务器返回 200 的那一刻，你的请求头、IP、TLS指纹、请求节奏，已经在 WAF 日志里被打上“可疑”标签——合规不是单点检查，是一整套行为模式的收敛。
Python免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 Python 的核心概念和高级技巧！
