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

9359075

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

/ P# ?0 |! `+ _3 {3 P: Q2 V) T2 k& kUSPTO：官方API的"绅士协议"


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

EPO：OAuth 2.0的"欧洲式严谨"

+ K$ m  g2 o8 H- c! Y7 W9 o8 F
. Y6 L' k2 U8 f9 `4 X- o欧洲专利局的API门槛明显更高。强制要求注册获取consumer_key和consumer_secret，采用OAuth 2.0的客户端凭证模式（Client Credentials Grant）。每次调用前要先拿access_token，token有效期10分钟。
这个设计增加了代码复杂度，但换来了更精细的配额管理。EPO给每个注册应用分配每日调用额度，付费 tier 可以提升到10万次/天。对于中小企业，免费额度通常够用。
认证流程需要Base64编码的凭证组合：
1 j% r" l3 v; K' U# d; u% d关键点：EPO的Range参数用"begin-end"的闭区间格式，和USPTO的start+rows逻辑不同。混用会导致数据重复或遗漏。
另一个坑是数据格式。EPO返回的XML/JSON混合了多种专利文献标准，同一条专利可能有多个publication-number（申请号、公开号、授权号）。做去重时建议用docdb格式的唯一标识符，而非直观的专利号字符串。
" G3 s$ F% U- n* Q. G: _实测发现EPO的搜索语法更接近传统检索系统。支持通配符（*）、邻近算符（near/within）、分类号前缀匹配。对于需要复杂检索式的场景，EPO的表达能力比USPTO强一个量级。

9 z7 z6 s1 ]5 x2 U0 L' S/ {Google Patents：动态渲染的"猫鼠游戏"
6 z( ~5 h- P4 i

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

$ s6 u! |0 `' G- ?# ^# S三种策略的选型决策树
6 Z) ]. z. f7 ~8 U: z1 _

; y0 t# c( E' @( g+ zUSPTO适合快速原型和美式专利追踪，代码最简单，数据最原始。缺点是仅限美国申请，且2015年前的专利数据格式混乱（从SGML迁移遗留的问题）。
9 G- ]  c, K( [6 u: `+ NEPO适合需要复杂检索和全球覆盖的场景。OAuth流程增加了初期成本，但数据规范性和多语言支持最好。特别注意：EPO的OPS API不包含全文文本，只有摘要和权利要求，全文需要额外调用其他服务。
9 a% G! e1 s! X- H) [1 o/ k' LGoogle 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分钟以内——但这不会发生。
; E5 z* I+ I6 m* w& {法律风险提示：三家平台的robots.txt和服务条款对爬虫态度不一。USPTO明确允许"reasonable automated access"，EPO要求"non-commercial use or commercial license"，Google Patents的Terms of Service禁止"automated means"访问。实际执行中，控制请求频率、不干扰正常服务、仅用于内部分析，通常不会触发法律行动。但大规模商业部署前，建议咨询知识产权律师。
. n) b7 H0 z/ U7 q; R& a最后放一段读者反馈。上周把USPTO的代码片段发给一位做医药情报的朋友，他当天下午就改出了监控特定IPC分类号（C07D/杂环化合物）的预警脚本。"以前每周花6小时刷EPO的检索式，现在每天早上收邮件就行。"