网页采集为什么要尊重robots和平台规则
网页采集不是只要技术能访问就可以抓取。robots.txt、平台条款、User-Agent 要求、速率限制和替代数据接口，都是采集系统上线前必须检查的边界。
网页采集常被误解成一个纯技术问题：能不能请求页面，能不能解析 HTML，能不能处理登录后的页面，能不能把数据存进数据库。可采集系统能跑起来，并不等于它适合上线。把采集任务放到生产环境时，更重要的问题是：站点是否允许爬虫访问这些路径，平台有没有公开 API 或数据下载方式，请求频率会不会影响对方服务，User-Agent 是否能让对方联系到你，收到 429 或 403 后系统会怎么处理。
这不是礼貌用语，而是工程边界。一个不看规则的采集脚本，短期可能拿到数据，长期会让项目承担三类风险：服务风险，采集行为可能给对方服务器造成压力；数据风险，采集到的数据可能来自不适合再分发或商业使用的页面；项目风险，平台可能限流、封禁、要求停止访问，甚至触发法律或合同层面的争议。
所以，网页采集的第一步不应该是写爬虫，而是确认规则。先看 robots.txt，再看平台条款、API 文档、User-Agent 政策、速率限制和数据授权说明。技术路线应该服务于这些边界，而不是把边界当作事后补丁。
robots.txt 解决的是什么问题
robots.txt 是站点放在根路径下的文本文件，用来告诉自动化客户端哪些路径可以访问，哪些路径不希望被访问。IETF RFC 9309 对 Robots Exclusion Protocol 做了标准化说明：服务所有者可以通过这个协议控制自动客户端如何访问内容；爬虫需要根据自己的 user-agent 找到匹配规则，再根据 allow 和 disallow 判断目标 URI 是否可访问。
这里有两个容易混淆的点。
第一，robots.txt 不是访问授权。RFC 9309 明确说明这些规则不是一种访问授权形式。换句话说，一个路径没有被 Disallow，不等于你获得了复制、存储、再分发或商业使用内容的许可。它只是在“自动客户端是否应访问这个 URI”这一层提供规则。
第二，robots.txt 不是安全机制。把敏感页面写进 Disallow 并不会阻止人类用户或不守规则的程序访问，也不会替代登录、权限、签名 URL 或后端鉴权。它更像是站点和自动客户端之间的一份访问约定：尊重它，是为了减少对服务的打扰，也为了让采集行为有可解释的边界。
因此，负责任的采集系统不只是在第一次启动时读一下 robots.txt。它应该定期刷新规则，按 host、protocol、port 区分适用范围，记录当时使用的规则版本，并在规则变化后重新评估采集队列。
平台规则比 robots.txt 更宽
很多网站的规则并不只写在 robots.txt 里。平台可能还有服务条款、开发者协议、API 使用指南、User-Agent 政策、速率限制说明、数据授权页面、商用许可说明。网页采集要尊重的是这一整组规则，而不是只找到一个没有被 Disallow 的 URL。
Wikimedia 的公开策略是一个典型例子。它不仅要求自动化客户端准确标识 User-Agent，还建议在可行时优先使用 dumps 或缓存接口，说明收到 429 时要尊重 Retry-After，并给出不同接口的并发和请求速率建议。它还明确提醒：不要伪装浏览器 User-Agent，不要用泛泛的 curl、python-requests 等默认标识去跑大量请求。
这类规则背后的逻辑很实际。平台不是反对所有自动化访问，而是希望访问者说明自己是谁、为什么访问、如何联系、请求量多大、是否有更低成本的数据入口。如果一个团队需要长期采集公开资料，清晰的身份、低冲击的请求方式、可沟通的联系方式，往往比“多开几个并发”更重要。
为什么 User-Agent 不只是一个请求头
很多初学者会把 User-Agent 当作浏览器伪装工具：把请求头改成某个浏览器字符串，页面就返回正常内容。对网页采集来说，这种做法很危险。它让平台无法区分正常浏览器和自动化程序，也让对方在请求异常时找不到负责人。
负责任的采集程序应该使用描述性 User-Agent，例如包含项目名、版本、说明页面或联系邮箱。Wikimedia User-Agent Policy 就要求自动访问者提供有信息量的标识和联系方式，并指出空 User-Agent、默认库名或复制浏览器标识都可能导致阻断。这个规则不是形式主义：当你的采集任务误触高频请求、错误路径、异常参数时，对方能够联系到你，比直接封禁整段 IP 更有利。
User-Agent 还会影响日志和审计。你需要知道某次请求来自哪个任务、哪个版本、哪个队列；对方也需要知道流量来源。一个清楚的 User-Agent，是两边都能追踪问题的基础。
429 是系统在说“慢一点”
网页采集最常见的冲突不是一次请求，而是大量请求。HTTP 429 Too Many Requests 表示客户端在某个时间窗口内发送了过多请求。MDN 对 429 的解释是：这是让客户端降低请求速率的机制；响应中可能包含 Retry-After，提示多久之后再试。
收到 429 后继续加速重试，是采集系统里非常糟糕的行为。正确做法是暂停当前 host 或当前账号的请求，读取 Retry-After，降低并发，拉长间隔，并把限流事件写进日志。对于长期任务，还应该把限流视为反馈：你的采集计划、并发数、缓存策略、增量方式可能需要调整。
平台规则里的速率限制不一定以 429 呈现。有的平台会返回 403，有的会在文档里写明每秒请求数，有的会要求使用 API key 或认证账号，有的会建议使用数据 dump。采集系统不能只认一个状态码，而要把“平台希望我如何访问”作为设计输入。
尊重规则不是降低效率
有人会觉得，遵守 robots 和平台规则会让采集变慢。短期看，确实可能不能随意抓取所有页面，也不能把并发开到很高。但从项目角度看，尊重规则反而提高可持续性。
第一，它减少无效开发。很多页面并不适合抓取：内容依赖前端渲染、URL 带会话参数、数据有版权限制、页面结构频繁变化。先看平台是否提供 API、RSS、sitemap、数据导出或 dump，往往比解析页面稳定。
第二，它减少服务冲突。使用缓存接口、批量接口、增量参数、压缩响应和合理间隔，可以降低双方成本。Wikimedia 机器人策略就建议在可行时使用 dumps，网页 HTML 走缓存友好的路径，API 请求按并发和速率限制执行。
第三，它让项目可审计。团队可以解释“为什么采这些页面、依据哪些规则、请求频率多少、如何处理拒绝、如何删除数据”。当采集结果要进入产品、报告或知识库时，这些证据比临时脚本更有价值。
采集前要回答的四个问题
第一个问题：这份数据有没有更正式的入口？如果平台提供 API、开放数据集、RSS、sitemap、bulk export、data dump，优先评估这些入口。网页 HTML 往往是给浏览器看的展示层，不一定是给批量处理设计的接口。
第二个问题：目标路径是否允许自动访问？检查 robots.txt，确认规则适用于当前 host、protocol、port 和 user-agent。不要把 example.com/robots.txt 套到 api.example.com，也不要把 HTTP 的规则套到 HTTPS 之外的服务。
第三个问题：平台是否有额外规则？阅读服务条款、开发者文档、API 使用政策、User-Agent 要求、速率限制、数据授权说明。尤其是有登录、付费、版权、个人信息、论坛社区、社交媒体内容的场景，平台规则可能比技术可访问性更重要。
第四个问题：如果对方拒绝或限流，系统如何停下来？采集系统应该有开关、限速器、重试上限、host 级暂停、错误队列和人工复核。不能让任务在收到 429、403、5xx 后持续高频请求同一个站点。
替代方案常常更好
尊重平台规则并不意味着放弃数据需求。很多时候，换一种入口更稳。
如果目标是公开百科、论文、政府数据、开源仓库、产品文档，优先找官方 API、数据 dump、RSS、站点地图或 Git 仓库。对于文档站，sitemap 可能比盲目递归链接更适合确定页面范围；对于大型知识平台，data dump 能避免给在线服务制造压力；对于需要实时更新的系统，API 的分页、游标和更新时间字段通常比 HTML 页面可靠。
如果平台没有开放数据入口，可以考虑降低采集范围：只采摘要，不采全文；只采公开列表页，不访问详情页；只采自己拥有授权的页面；只做人工触发，不做持续爬取；只保存引用和元数据，不保存受限制内容。技术上能抓到，并不代表产品上必须保存全部内容。
如果业务确实需要高频或大规模访问，建议联系平台申请合作、提高配额或使用商业数据服务。把需求说清楚、把请求量说清楚、把 User-Agent 和联系页面准备好，往往比绕开限制更稳。
采集系统应该留下哪些证据
对于数据团队来说，尊重规则不能只靠口头承诺，需要落实到日志和配置里。
规则证据：保存采集前读取的 robots.txt 内容、读取时间、适用 host、匹配到的 user-agent 组、allow/disallow 判断结果。平台证据：保存条款、API 文档、速率限制和数据授权页面链接，记录版本或访问时间。请求证据：记录 User-Agent、并发数、请求间隔、状态码分布、429/403/5xx 处理。数据证据：记录数据来源 URL、采集时间、字段处理方式、是否包含个人信息或受限内容。操作证据：记录谁开启任务、为什么开启、如何停止、是否经过人工复核。
这些记录不是为了写漂亮文档，而是为了在问题出现时能追溯：某条数据从哪里来，采集时规则是什么，系统是否尊重了拒绝信号，是否存在超出范围的请求。
常见误区
误区一：没有登录就可以任意采集。公开可访问不等于无限制采集，也不等于可以再分发。公开页面仍可能受平台条款、版权、数据库权利、隐私规则或社区规则约束。
误区二：robots.txt 允许访问就等于可以商用。robots 解决的是自动访问路径，不解决内容许可、数据授权、再分发和商业使用问题。
误区三：把 User-Agent 改成浏览器更安全。对高频自动化访问来说，伪装浏览器可能让流量更可疑，也会让平台更难沟通。描述性标识更适合长期任务。
误区四：限流只是技术障碍。429、Retry-After、并发限制、API 配额都是平台在表达容量和规则。把它们当作反馈，才是工程上可持续的做法。
误区五：只要加代理就能解决。代理可能隐藏了请求来源，却没有解决授权、速率、平台规则和数据使用边界。它还可能让问题扩大到网络信誉和账号安全层面。
落地清单
上线前，可以用下面这张清单检查采集任务。
第一，是否确认目标数据的用途、保存周期和使用范围。第二，是否检查 robots.txt，并把判断结果记录下来。第三，是否阅读平台条款、API 文档、User-Agent 政策和速率限制。第四，是否优先评估 API、RSS、sitemap、dump、授权数据源等替代入口。第五，是否设置描述性 User-Agent 和联系方式。第六，是否设置 host 级限速、并发上限、退避策略和 429/Retry-After 处理。第七，是否保存来源、规则、请求和处理日志。第八，是否为敏感内容、个人信息、版权内容设置人工复核。第九，是否有停止任务和删除数据的操作路径。第十，是否有人对采集范围和输出结果负责。
网页采集的成熟度，不是看脚本能抓多少页面，而是看它能不能在规则内稳定运行。尊重 robots 和平台规则，实际是在保护三个对象：对方服务的稳定性，自己项目的可持续性，以及数据使用的可解释性。
