Python谷歌爬虫教程：多引擎并行+真链还原+Excel导出

Python谷歌爬虫教程多引擎并行真链还原Excel导出先放实测结论同一批 5 个关键词、每词要 10 条本机直连跑下来——Bing 平均 435 毫秒、五个词全中360 平均 1283 毫秒、五个词全中百度五个词一个没出来全部被人机验证拦下。但用户那边看到的结果是五个词全部拿到 10 条。差别在于工具跑的是「智能模式」——前面的通道跪了后面的顶上够量就停。这篇讲的是做这样一个能交到客户手上的采集工具真正卡住我的五个地方以及每一处对应的代码对策。所有数字都是本机跑出来的不是估的。一、交付形态决定技术选型做之前先想清楚一件事这个是给谁用的。自用脚本和客户要的工具评价标准完全不同。自用脚本崩了你自己看一眼报错就行客户拿到的是双击一个启动.bat中间任何一步出错都得有人背。所以选型上我定的三条约束对策客户机器可能什么都没有自带浏览器降级链本机 Chrome → 系统 Edge → 内置 Chromium客户不懂代理和 Key免 Key 免代理通道打头阵需要代理的通道放最后采集中途出问题不能崩每个通道失败只记一行日志自动换下一个最终成品的形态是双击一个 bat浏览器自动打开操作页粘贴订阅链接 → 填关键词 → 导出 Excel。这张图怎么看真正有价值的不是中间那六步是第二步的「够量即停」——它把后面所有通道的不确定性都挡在了用户看不见的地方。一版界面真实长这样不是示意图是交付给客户的测试版本二、四个通道的实测差别比想象中大先看数据。环境是本机直连、无代理5 个关键词跨境电商 独立站 / 新能源汽车 / 外贸建站 / 人工智能 / 海外仓每个词目标 10 条通道成功平均耗时最快一次备注Bing RSS5/5435 ms206 ms固定约 10 条不翻页360 搜索5/51283 ms774 ms属性里直接给真链智能模式5/5425 ms198 ms首选 Bing够了就停百度0/5740 ms—全部返回人机验证页有两点值得单独拎出来说。第一Bing 的 RSS 是被低估的入口。很多人第一反应是拿requests去请求 Bing 的结果页然后发现返回的永远是首页——因为 HTML 结果页对非浏览器客户端会重定向。但 Bing 的 RSS 接口?formatrss是稳的纯 HTTP、不用 JS、不用 Key我这边最快一次 206 毫秒出 10 条。第二百度这次是 0/5我反而不打算修它。缓存里留着前一天的记录同一个词百度给过 1 条、给过 3 条、也给满过 10 条——典型的触发了频控。这类波动修不好也不该硬碰。正确做法是把它排在降级链里有就收没有就过。这里有个很容易忽略的点智能模式耗时 425 ms比单独跑 Bing 的 435 ms 还快一点。不是它更快是它决策早——第一个通道够量就停没有多余请求。三、坑一市场参数不写死结果就跑偏这是踩的第一个坑也是最隐蔽的一个。早期的版本写完就能跑结果客户反馈结果跟关键词对不上。查下来是这句hlopts.get(mkt)oropts.get(gl_hl)orzh-CNcchl.split(-)[1].upper()if-inhlelseCNurl(f{BING_RSS_HOST}/search?q{urllib.parse.quote(keyword)}fformatrssmkt{hl}setlang{hl}cc{cc})mkt和cc必须显式传。不传的话搜索引擎会按出口 IP 所在地给你返回结果。客户那边关键词是「新能源汽车」经某个日本节点出去拿回来的是新字的词典解释和一堆无关问答。这事麻烦在于它不报错。请求 200解析出 10 条一切正常只是内容文不对题。等你发现的时候Excel 已经导出交出去了。顺着这个坑还有个连带结论国内引擎Bing / 百度 / 360必须直连。它们和 Google 相反——走境外出口不但没好处反而会因为出口所在地不同返回一堆当地语言的结果。所以代码里专门分了两个会话def_cn_session(opts):国内引擎专用会话优先用无代理的那个returnopts.get(session_direct)oropts[session]一句话总结免代理通道就老老实实直连别让代理把你的市场参数搅了。四、坑二并发会把客户机器直接干趴第二个坑更狠表现是客户说卡一下就没了。根因是浏览器的并发模型。Playwright 的同步 API 绑定线程不能跨线程并发而 Google 这类通道又要多路出口同时打。关键词并发 4 × 每词开 4 路出口 Chrome 十几个浏览器窗口同时跑一个 Chrome 占 400~700MB普通机器当场卡死。代码里现在是这么防的——先判这次任务要不要开浏览器要开就强制串行def_needs_browser(engine,want):# 注意任何 Google 家族与 Brave 都必须走浏览器。# 漏判的后果很严重会被当成免浏览器通道而并发 4 个关键词# 每个又开多路出口 Chrome 到十几个 Chrome 同时跑客户机器直接卡死。ifany(pin(google,google_free,google_paid,brave)forpinparts):returnTrue再叠一道信号量掐住同时存在的浏览器数量MAX_CHROMEmax(1,int(os.environ.get(GS_MAX_CHROME,3)or3))_CHROME_SEMthreading.Semaphore(MAX_CHROME)并发只对免浏览器通道有意义。实测里 Bing RSS 和 360 是纯 HTTP开 4 个线程跑是真能提速的一旦涉及浏览器老实串行比什么都稳。采集界面上的实时日志就是为这种看一眼知道它在干嘛的场景准备的五、坑三链接不一定是链接第三个坑藏在数据质量里搜索引擎给你的 href不等于真实网址。三种形态处理方式完全不同360 最省心data-mdurl属性里直接写着完整地址拿走即用百度要还原www.baidu.com/link?urlxxx是跳转壳必须让会话跟进重定向才能拿到真地址相对路径或空直接丢。宁可少几条也不要把/search?qxxx这种东西导进 Excel 给客户。除了跳转外壳本身还有一层噪声要滤搜索站自己的域名google.com、bing.com、microsoft.com这类、以及广告。广告识别靠的是标题 摘要 class 里有没有暗示词AD_HINTS(广告,赞助内容,赞助,sponsored,promoted,ad ·,ad·)实测这层过滤不是摆设。前一天的缓存里有这么几组关键词「海外营销」10 条里滤掉 4 条广告「独立站推广」同样 4 条「外贸建站」2 条。也就是说如果你不做这一步导出去的表里有 20%~40% 是花钱买的位子。六、坑四多引擎组合别让第一个吃独食做一个全能三合一Bing Google 360的时候踩的。第一版逻辑是按顺序调用把结果去重合并够want条就停。写完跑出来一看——Google 和 360 一条都没进表。原因很简单Bing 第一个跑直接就占满了 10 条的配额轮到后面两个的时候额度已经是 0。改成配额均摊permax(3,-(-want//max(1,len(parts))))# 向上取整顺手加了一个 SearXNG 的思路同一条结果被多个引擎同时收录说明它更权威排名该提前。hits{}forpinparts:forrinout[results]:hits.setdefault(r[url],set()).add(p)merged.sort(keylambdar:(-r.get(hits,1),r.get(rank)or999))多引擎的价值本来就不是条数更多是交叉验证。只在一个引擎排第一的结果和两个引擎都排在前面收录的结果含金量不一样。七、二级抓取真实世界的成功率就是不到一半一级拿到标题和链接之后还有个可选环节进结果页抓正文顺带提取邮箱、电话、微信号。我拿关键词「外贸建站」的前六条跑了一遍结果字数耗时状态个人博客长文65513.7 s正常服务商官网页24230.8 s正常外贸咨询站5804.8 s正常知乎专栏两条01.3~1.8 s被站点挡回建站工具站06.5 s内容偏少六条里成了三条。这个成功率我写进交付文档了没打算粉饰——二级抓取访问的是别人的网站对方挡你是天经地义。至于联系方式提取这一轮五个邮箱电话都没捞到。做的时候我把这段如实标成本次样本未提取到而不是假装它有。三条能提高命中率的经验请求头要像浏览器。很多站点百度百科是典型缺了Sec-Fetch-*、Upgrade-Insecure-Requests这几个头直接 403被拒之后带个 Referer 再试一次。403 / 429 的站点里有相当一部分只是认 Referer带上本站地址就放行了编码别信resp.encoding。取站定声明、apparent_encoding、utf-8、gb18030都试一遍数\ufffd和锟斤拷谁最少用谁。百科类页面还有个专门的坑不显式指定容器选择器会误把侧栏的相关新闻列表当正文。所以选择器池里专门塞了[class*lemma]、[class*summary]、[class*para]这几条。正文页长这样八、节流与合规这段比技术更重要采集搜索结果这件事技术上能做的和合规上该做的边界要自己划清楚。这个工具里落地了几条硬约束全局限速任意两次请求之间至少间隔 1.2 秒 随机抖动所有通道共用失败即退HTTPAdapter(max_retries0)网络不通就快速失败不做无意义重试也不给人程序卡住的错觉不破解验证遇到人机验证不会去碰它而是记录、换通道、把该出口放进冷却冷却期内不再打扰出口轮换而非穷举实测踩过一次教训——快速轮测 8 个节点结果整个网段被打死100% 被拦二级抓取限量默认只对前 3~5 条结果抓正文不给目标站点添麻烦。关于 Google 那条路我的建议很明确量大就走付费 SERP API。单价折下来最低约 ¥0.0006/次一万关键词约合 ¥40不算昂贵换来的是不用碰反爬、结果稳定、出量也不看对方脸色。填个 Key 就能跑不用维护节点也不用算风控。相比之下靠自采硬扛机房 IP 的声誉劣势性价比远不如直接买 API。最后数据只用于你有权使用的场景自家关键词的排名追踪、公开市场调研、竞品分析遵守目标站 ToS 与所在地法规。这点不是免责摆设是能不能长期用的前提。九、如果你要自己写一个最少三层就够不需要一上来就做这么复杂。这套结构抽出来三层足够应付日常网络层UA 池 限速退避 出口健康度。这一层决定能不能长期跑解析层多套选择器兜底 广告过滤 真链还原。这一层决定数据干不干净调度层队列 失败重跑 中断。这一层决定能不能交给别人用。再加一句经验先把降级链写进去再考虑优化单个通道。单个通道优化到极限也扛不住对方一次改版有降级链的工具百度 0/5 那天的表现依然是五个词全中。这张图怎么看左边那一列不是错自用脚本这么做完全合理。差别在于右边每一条都在回答同一个问题——如果这一步出问题了谁来兜。十、几个可以直接抄的细节问题对策结果条数比目标少正常。去重和真链还原会自然丢几条别强行补足同一批词第二次特别快命中本地缓存默认 24 小时内同词同引擎不重复请求上次没抓详情、这次勾了详情却说命中缓存会自动补抓缺的那几项抓完写回缓存想只重跑失败的词任务结束后点「重跑失败项」用同样设置只跑失败的部分百度时好时坏别修它。把它放在降级链里就行导出 CSV 用 Excel 打开乱码必须写 UTF-8 BOM这是 Excel 的老毛病你的采集脚本现在用的是哪个入口requests 硬啃 HTML、Selenium、还是已经转 RSS 了评论区报一下你那边的实测耗时凑够二十个样本我出一张不同地区的速度表。如果这篇对你有用点赞 收藏——下一篇写多引擎融合排序那部分的完整实现含融合打分那部分怎么调参。说明文中全部实测数据为本机 2026-09-23 直连环境下的真实采集记录5 个关键词 × 4 通道目标 10 条/词二级抓取数据为关键词「外贸建站」前六条结果的真实抓取结果耗时受本机网络与目标站点当时状态影响不同环境会有出入仅供参考。文中涉及的通道选择、降级与节流策略均为工程实践记录请在使用前确认目标站点服务条款与所在地法律法规对非自有资产请先取得授权。