美国专利局1秒限1次请求，爬虫工程师用这招绕过

9359075

美国专利商标局（USPTO）的开放数据接口每秒只允许1次请求，欧洲专利局（EPO）强制OAuth 2.0认证，Google Patents干脆用JavaScript动态渲染——三家主流专利数据库，三种完全不同的反爬策略。一位做竞争情报的产品经理算过账：手动检索5000条专利信息，熟练工需要40小时；写个靠谱的爬虫，2小时搭建，10分钟跑完。
+ O$ p  ^7 G# O" a& F7 R# m专利数据的价值被严重低估。药企追踪竞争对手的化合物专利布局，硬科技公司监控标准必要专利（SEP）的授权动态，投资机构用专利引用网络预测技术并购标的。这些信息全部公开，但分散在三个体系、五种格式、无数分页里。
( T( K; q' \) C( e0 \3 l- w) \* I本文提供可直接运行的代码框架，覆盖USPTO、EPO、Google Patents三大数据源。不需要你懂自然语言处理，不需要部署分布式集群，一台笔记本就能启动。
, J+ q3 _" U- f5 v. n
USPTO：官方API的"绅士协议"
1 B- \, N( a2 ~  X

美国专利商标局算是态度最友好的。他们提供RESTful API，文档完整，甚至不用注册就能调用。但有个隐性规则：官方建议每秒不超过1次请求。这不是技术限制，是写在服务条款里的"绅士协议"。
违反的后果很实在——IP进黑名单，24小时解封。对于需要批量获取的用户，这个限速意味着检索10万条专利需要27小时以上。
解决方案藏在请求节奏里。下面这个类封装了自动延迟和分页逻辑：
9 A4 G$ J4 o# }, v% `- D) H核心设计：用time.sleep(self.delay)强制节流，用Session复用TCP连接减少握手开销。
: m* A% R/ |: W  T- V# A代码里的search_all方法实现了"懒加载"式分页——不预设总页数，拿到空结果就停。这种设计对USPTO特别重要，因为他们的搜索结果集大小不固定，last-modified-date字段可能让同一查询返回不同数量的记录。
一个细节：USPTO的返回字段命名极其美式。inventionTitle是发明名称，firstNamedApplicant是第一申请人，publicationDate用YYYYMMDD字符串而非时间戳。做数据清洗时记得统一格式，否则下游分析会踩坑。
实际跑测，查询"artificial intelligence"返回的50条记录中，有3条的inventionTitle字段为空。USPTO的数据质量并非完美，空值处理必须写进生产代码。

4 v7 }2 h# h" t" ?) a! v. xEPO：OAuth 2.0的"欧洲式严谨"
6 R- W* I$ V1 d

欧洲专利局的API门槛明显更高。强制要求注册获取consumer_key和consumer_secret，采用OAuth 2.0的客户端凭证模式（Client Credentials Grant）。每次调用前要先拿access_token，token有效期10分钟。
  X$ `  E, F6 L8 [7 X/ M这个设计增加了代码复杂度，但换来了更精细的配额管理。EPO给每个注册应用分配每日调用额度，付费 tier 可以提升到10万次/天。对于中小企业，免费额度通常够用。
3 K6 a( R, ^( U8 f, Z5 n0 o: {认证流程需要Base64编码的凭证组合：
7 U* p* Z! c6 _& ?关键点：EPO的Range参数用"begin-end"的闭区间格式，和USPTO的start+rows逻辑不同。混用会导致数据重复或遗漏。
5 G! ]+ _6 D0 ~! A- s另一个坑是数据格式。EPO返回的XML/JSON混合了多种专利文献标准，同一条专利可能有多个publication-number（申请号、公开号、授权号）。做去重时建议用docdb格式的唯一标识符，而非直观的专利号字符串。
实测发现EPO的搜索语法更接近传统检索系统。支持通配符（*）、邻近算符（near/within）、分类号前缀匹配。对于需要复杂检索式的场景，EPO的表达能力比USPTO强一个量级。

& Q& c7 p7 z# @" k. J0 y3 LGoogle Patents：动态渲染的"猫鼠游戏"
$ e( y9 I1 W0 S6 k5 A

Google Patents没有官方API。这个聚合平台从USPTO、EPO、WIPO等数十个来源抓取数据，做语义增强和机器翻译，然后以免费搜索的形式呈现。数据最全，反爬也最严。
0 }' _! a% B8 j; b$ y1 A4 _4 w! j$ U) C直接请求HTML会拿到骨架页面，专利详情藏在JavaScript渲染后的DOM里。传统requests库束手无策，必须上浏览器自动化工具。
Playwright是目前的最优解。相比Selenium，它的定位更精准，等待机制更可靠，对现代前端框架（React/Vue）的兼容性更好。
0 Z9 h  V& y3 a/ i0 d* y6 F基础架构：用sync_playwright启动Chromium，设置viewport和user-agent模拟真实用户，等待networkidle确保动态内容加载完成。
反反爬的关键细节：headless=False能降低检测概率，但牺牲性能；route方法拦截图片和字体请求，减少80%以上的带宽消耗；page.wait_for_selector确保目标元素出现后再提取，避免竞态条件。
1 Z& q7 g9 D  }' C* U3 O$ k2 n6 j; @Google Patents的页面结构经常微调。2024年3月的一次更新把专利标题从h1.item-title改成了span[data-target="title"]，导致大量旧爬虫失效。生产环境建议用相对稳定的文本特征定位，比如包含"Patent"的meta标签，而非硬编码CSS选择器。
# M% ~' W$ J7 j2 x* o! @数据提取后会发现，Google做了大量衍生计算。同族专利聚合、引用网络可视化、法律状态时间线——这些增值信息在原始专利数据库里分散在多张表，Google帮你JOIN好了。代价是字段命名完全不遵循任何标准，需要额外映射层。
7 |" i! E% {4 u1 J8 T
! o! }" m* D' F* R  A三种策略的选型决策树
5 k1 I/ Z2 u2 v' ?5 v. }& F) }

USPTO适合快速原型和美式专利追踪，代码最简单，数据最原始。缺点是仅限美国申请，且2015年前的专利数据格式混乱（从SGML迁移遗留的问题）。
+ u% P) r8 G6 l, B: l/ g# {; v4 B0 f' g4 KEPO适合需要复杂检索和全球覆盖的场景。OAuth流程增加了初期成本，但数据规范性和多语言支持最好。特别注意：EPO的OPS API不包含全文文本，只有摘要和权利要求，全文需要额外调用其他服务。
% z) l8 G8 p8 H  X3 xGoogle Patents适合需要"开箱即用"的聚合数据，尤其是引用分析和同族专利映射。反爬对抗是持续成本，适合有运维资源的中长期项目。
一个混合策略：用USPTO/EPO的官方API获取基础元数据，用Google Patents补充引用关系和语义标签。两者通过公开号（publication number）关联，匹配率通常在95%以上。
性能基准：在同一台MacBook Pro M3上，USPTO爬虫跑1000条记录耗时18分钟（受限于1秒延迟），EPO耗时12分钟（网络延迟更低），Google Patents用Playwright耗时47分钟（浏览器开销）。如果Google解除反爬，纯HTTP请求能把时间压到3分钟以内——但这不会发生。
法律风险提示：三家平台的robots.txt和服务条款对爬虫态度不一。USPTO明确允许"reasonable automated access"，EPO要求"non-commercial use or commercial license"，Google Patents的Terms of Service禁止"automated means"访问。实际执行中，控制请求频率、不干扰正常服务、仅用于内部分析，通常不会触发法律行动。但大规模商业部署前，建议咨询知识产权律师。
最后放一段读者反馈。上周把USPTO的代码片段发给一位做医药情报的朋友，他当天下午就改出了监控特定IPC分类号（C07D/杂环化合物）的预警脚本。"以前每周花6小时刷EPO的检索式，现在每天早上收邮件就行。"