做爬虫这行当久了你会发现一个很有意思的现象很多人把爬虫简单理解为“用代码把网页源码拉下来再拆拆字段”可真到了复杂场景——网页是JavaScript动态渲染的、目标数据藏在iframe里、网站反爬策略三天两头换——光靠一个库一把梭早就行不通了。今天我想聊的这套组合拳不是什么神秘黑科技而是我自己在实战里反复打磨出来的一套方案以Scrapy作为调度和抓取的骨架用BeautifulSoup负责页面解析和字段提取再在必要时引入Playwright处理动态渲染页面和iframe嵌套。这三大件各管一段配合得当几乎能覆盖日常工作中90%以上的抓取需求。这篇文章适合谁一是刚学完Python基础、准备上手爬虫的开发者二是已经用Scrapy写过简单爬虫、但一碰到动态页面就抓瞎的进阶用户。我会把从环境搭建、工程结构、核心解析逻辑到动态页面处理和反爬应对的完整链路都拆给你看里面不少细节是我踩过坑之后才悟出来的。1. 内容整体设计与思路拆解1.1 为什么是“BS4 Scrapy”而非单一框架先说个最常见的误区。不少人一上来就迷信Scrapy觉得它功能全、性能强什么页面都能搞定。实际上Scrapy最擅长的是“批量抓取 全站遍历”这类规模化任务它内置了调度器、去重队列、并发机制、中间件体系确实是重型武器。但它的短板也很明显页面的解析和字段提取写起来相对笨重尤其遇到那种结构混乱、没有规范class的HTML用Scrapy自带的Selector写XPath或CSS表达式能把人逼疯。反过来BeautifulSoup后文统称BS4在单页面解析上的体验极为顺手它容忍破损HTML的容错性极强配合lxml解析器之后查找元素、遍历节点、提取文本都非常直观。但BS4没有并发调度、没有请求去重、没有下载中间件你拿它写大规模爬虫最后一定会在自己写的“伪调度器”里翻车。所以我的方案是用Scrapy管“怎么抓、抓多少、怎么不重复抓”用BS4管“抓下来的页面怎么拆、字段怎么提”两者各自干自己最擅长的事。实力上不是替代关系而是互补关系。1.2 三层架构调度层、渲染层、解析层我在实际项目里把整个爬虫系统抽象成三层调度层Scrapy核心负责请求队列、并发控制、去重、重试、管道输出。这一层解决的是“批量稳定地拿回HTML”的问题。渲染层Playwright中间件解决动态渲染和iframe嵌套问题。网站数据如果是前端JS异步加载或者藏在多层iframe里直接请求URL拿到的HTML是残缺的必须用无头浏览器执行脚本后再取页面内容。解析层BS4负责从已经就绪的HTML里提取目标字段做数据清洗和结构化。这三层各管一头互不越界。最核心的设计心法是解析层绝不发请求调度层绝不碰HTML解析。很多新手写爬虫容易把代码糊成一团一个函数里既发请求又拆数据最后维护成本极高。分层的好处是任何一层出了问题只需要替换该层的实现不影响整体。1.3 这套组合能解决什么场景问题结合我接触过的实际需求这套组合主要覆盖以下几类场景新闻/资讯类采集页面结构相对规范但字段多、列表分页复杂BS4可以把标题、时间、正文、来源一次性提取干净。电商商品信息价格、库存、评价数量常藏在多级结构中部分字段需要进详情页二次抓取Scrapy的Request回调机制天然适配。数据报表类抓取不少管理系统把数据放在iframe里且需要登录态Playwright渲染层加上cookie注入就能搞定。JS强渲染的单页应用比如Vue/React写的前端页面纯请求拿不到数据必须走渲染层。一句话总结静态页用BS4爽快解析动态页用Playwright兜底渲染调度和去重全部交给Scrapy这就是这套组合的立身之本。2. 环境准备与工程搭建2.1 依赖安装与版本选择先把基础环境理清楚。我平时用Python 3.10/3.11强烈建议用虚拟环境别把依赖直接装到系统Python里。核心依赖就这么几个pip install scrapy beautifulsoup4 lxml playwright pymongo playwright install chromium几个依赖的定位说明一下scrapy主框架负责调度、下载、并发。beautifulsoup4HTML解析配lxml解析器速度最快容错也好。playwright无头浏览器专门应付JS动态渲染和iframe。不选Selenium是因为Playwright的API更现代自带wait机制处理动态元素比Selenium的time.sleep优雅太多。pymongo后文数据存储用MongoDB做持久化。安装完playwright后一定要执行playwright install chromium把浏览器内核下载下来。顺手装一下playwright install --with-deps chromium可以避免系统缺少动态库导致的启动崩溃。2.2 创建Scrapy项目与目录结构用Scrapy自带命令快速建项目scrapy startproject web_scraper cd web_scraper scrapy genspider news_spider example.com生成后的核心目录长这样web_scraper/ ├── scrapy.cfg ├── web_scraper/ │ ├── __init__.py │ ├── items.py # 数据模型定义 │ ├── middlewares.py # 下载中间件Playwright集成处 │ ├── pipelines.py # 数据处理管道清洗、去重、存储 │ ├── settings.py # 全局配置 │ ├── spiders/ │ │ └── news_spider.py我习惯把items.py当作数据模型定义文件。别小看这一步先定义好目标字段结构后面写Spider、写管道都会顺畅很多。比如我要抓资讯文章Item可以这样定义# web_scraper/items.py import scrapy class ArticleItem(scrapy.Item): title scrapy.Field() url scrapy.Field() source scrapy.Field() publish_time scrapy.Field() content scrapy.Field() tags scrapy.Field()2.3 Settings中的关键配置settings.py里有几个参数我必须提前说明因为直接关系到最后能不能稳定抓取# 爬虫优先级和并发设置 CONCURRENT_REQUESTS 8 DOWNLOAD_DELAY 1.0 RANDOMIZE_DOWNLOAD_DELAY True # 关闭默认去重使用自定义去重 DUPEFILTER_CLASS scrapy.dupefilters.RFPDupeFilter # 启用自定义中间件 DOWNLOADER_MIDDLEWARES { web_scraper.middlewares.PlaywrightMiddleware: 543, } # 启用管道 ITEM_PIPELINES { web_scraper.pipelines.MongoDBPipeline: 300, }DOWNLOAD_DELAY设成1.0秒是给目标网站减压顺带降低被封风险。RANDOMIZE_DOWNLOAD_DELAY让Scrapy在0.5到1.5倍之间随机波动延迟这让请求节奏更接近人工浏览。3. 核心实战融合抓取的完整链路3.1 用BS4解析静态页面定位、提取、清洗先看一个最基础的静态页面解析。在Spider的parse方法里拿到响应后直接用BS4处理# web_scraper/spiders/news_spider.py import scrapy from bs4 import BeautifulSoup from web_scraper.items import ArticleItem class NewsSpider(scrapy.Spider): name news_spider allowed_domains [example.com] start_urls [https://example.com/news] def parse(self, response): soup BeautifulSoup(response.text, lxml) # 定位列表区域的容器 article_list soup.select(div.news-list div.news-item) for article in article_list: item ArticleItem() # 标题优先取h2里的a标签文本 title_tag article.find(h2).find(a) if article.find(h2) else None item[title] title_tag.get_text(stripTrue) if title_tag else item[url] response.urljoin(title_tag[href]) if title_tag else # 摘要 desc_tag article.find(p, class_summary) item[content] desc_tag.get_text(stripTrue) if desc_tag else item[source] example.com # 分页找下一页链接 next_page soup.select_one(a.next) if next_page: yield scrapy.Request(response.urljoin(next_page[href]), callbackself.parse) yield item这里有几个细节我要特意强调第一get_text(stripTrue)是所有解析的标配。网页文本里塞满了空格、换行、\t如果不strip入库的数据全是脏的后面清洗代价更大。第二用response.urljoin处理相对链接。页面里href经常是/news/detail?id123这种相对路径直接存下来没意义。urljoin会基于当前页面URL自动拼接成完整地址。第三BS4的select和find混用是常态。分页导航这类结构清晰的地方用CSS选择器文章区域这种嵌套深、class多的情况用find链式查找更直观。两种方式互补不必纠结用哪个。第四注意空值保护。article.find(h2)返回None时链式调用会直接抛AttributeError。所以每一级查找都要做空值判断。我吃过这个亏抓几千条数据后程序崩溃排查半天才发现是某一篇文章少了h2标签。3.2 动态页面与iframePlaywright中间件的正确姿势静态页面的处理相对简单动态页面才是劝退大多数人的地方。这里的难题有两个一是数据是JS异步请求加载的直接请求URL返回的HTML没有数据二是数据被塞在iframe里主文档里压根看不到。我之前试过Selenium硬等time.sleep速度慢还容易误判加载完成。后来换了Playwright用显式等待替代固定等待稳定性提升了一个量级。我设计了一个下载中间件专门处理需要渲染的请求# web_scraper/middlewares.py from scrapy.http import HtmlResponse from playwright.sync_api import sync_playwright class PlaywrightMiddleware: 对需要JS渲染的请求执行Playwright浏览器渲染 def process_request(self, request, spider): # 如果没有开启渲染标记直接放行给Scrapy的默认下载器 if not request.meta.get(render_js): return None with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context( user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36, viewport{width: 1280, height: 800} ) page context.new_page() # 等待网络空闲比固定time.sleep靠谱 page.goto(request.url, wait_untilnetworkidle, timeout30000) # 处理iframe嵌套切换进入指定iframe取内容 # 更稳妥的做法递归查找所有iframe取src包含关键字或内容最丰富的那一层 target_frame None for frame in page.frames: if data in frame.url or content in frame.url: target_frame frame break if target_frame: target_frame.wait_for_selector(div.article-content, timeout10000) html target_frame.content() else: html page.content() browser.close() return HtmlResponse(urlrequest.url, bodyhtml, requestrequest, encodingutf-8)用的时候只需要在Spider的Request里带上meta{render_js: True}def parse_list(self, response): soup BeautifulSoup(response.text, lxml) for link in soup.select(a.article-link): yield scrapy.Request( urlresponse.urljoin(link[href]), callbackself.parse_detail, meta{render_js: True} )这里有几个教训第一等待条件选networkidle不一定最优。如果页面里一直有轮询请求networkidle可能永远等不到最后超时。遇到这种页面我建议换成domcontentloaded然后针对目标元素做wait_for_selector等组件出现才是真正的准。第二page.frames里包含主文档和所有iframe。主文档的frame.url是当前页面地址iframe有各自独立的URL。判断哪个iframe才是目标不能靠猜要结合URL关键字或页面内容特征。我踩过的坑是页面里有三个iframe两个是广告一个才是数据区一开始没做过滤抓回来全是广告内容。第三同步API还是异步API的选择。Playwright同时提供sync_playwright和async_playwright。Scrapy的下载中间件是同步调用模型用sync_playwright足够代码也容易理解。没必要为了“性能”强行上异步复杂度上去了收益却有限。3.3 Item Pipeline数据清洗、去重与入库解析层提取的原始数据通常不能直接用需要在管道里做二次处理。我习惯把Pipeline拆成三个环节清洗、去重、存储。先看清洗管道的写法# web_scraper/pipelines.py import re from pymongo import MongoClient class DataCleanPipeline: 字段清洗去空格、去HTML标签、格式化时间 def process_item(self, item, spider): # 标题清洗 if item.get(title): item[title] re.sub(r\s, , item[title]).strip() # 正文清洗去掉多余空白符 if item.get(content): item[content] re.sub(r\n\s*\n, \n, item[content]).strip() # 时间统一成ISO格式 if item.get(publish_time): # 实际根据目标站点的格式写正则匹配 item[publish_time] item[publish_time].replace( 年, -).replace(月, -).replace(日, ) return item清洗完成后是去重。Scrapy自带基于URL的去重但很多时候URL不同、内容相同。比如带参数的重定向URL或者一稿多发。这种场景我建议加一层基于标题MD5指纹的去重import hashlib class DuplicatesPipeline: 基于标题指纹的重复检查 def __init__(self): self.seen set() def process_item(self, item, spider): title item.get(title, ) fingerprint hashlib.md5(title.encode(utf-8)).hexdigest() if fingerprint in self.seen: raise DropItem(f重复内容: {title}) self.seen.add(fingerprint) return itemraise DropItem是Scrapy管道里最实用的技巧之一。它能在管道中途丢弃数据后面所有管道都不会执行自然也不会入数据库。这个机制比返回None再判断要干净得多。最后是MongoDB存储class MongoDBPipeline: def __init__(self, mongo_uri, mongo_db): self.mongo_uri mongo_uri self.mongo_db mongo_db self.client None self.db None classmethod def from_crawler(cls, crawler): return cls( mongo_uricrawler.settings.get(MONGO_URI, mongodb://localhost:27017), mongo_dbcrawler.settings.get(MONGO_DATABASE, spider_data) ) def open_spider(self, spider): self.client MongoClient(self.mongo_uri) self.db self.client[self.mongo_db] def close_spider(self, spider): self.client.close() def process_item(self, item, spider): collection self.db[spider.name] collection.insert_one(dict(item)) return item注意from_crawler这个类方法。它能让Pipeline从settings.py里读取配置这是Scrapy官方推荐的方式。千万别写死在代码里否则换环境部署、换数据库地址的时候要改源码太折腾了。3.4 爬虫主逻辑列表页与详情页的衔接一个稍微复杂点的场景是列表页给摘要和链接详情页给正文。这需要Scrapy的请求回调机制来串联。我把常见的写法拆解一下class NewsSpider(scrapy.Spider): name news_spider allowed_domains [example.com] start_urls [https://example.com/news] def parse(self, response): soup BeautifulSoup(response.text, lxml) for link in soup.select(div.news-list a.article-link): yield scrapy.Request( urlresponse.urljoin(link[href]), callbackself.parse_detail, meta{title: link.get_text(stripTrue)} ) # 翻页 next_page soup.select_one(a.next-page) if next_page: yield scrapy.Request( urlresponse.urljoin(next_page[href]), callbackself.parse ) def parse_detail(self, response): soup BeautifulSoup(response.text, lxml) item ArticleItem() # meta里的数据直接继承 item[title] response.meta.get(title, ) item[url] response.url content_div soup.find(div, class_article-detail) if content_div: # get_text提取所有段落文本 分隔避免粘在一起 item[content] content_div.get_text(separator , stripTrue) # 动态详情页标记渲染需求 if soup.find(div, idjs-content) is None: yield scrapy.Request( urlresponse.url, callbackself.parse_detail_dynamic, meta{render_js: True, item: item} ) else: yield item这里有个细节meta参数除了能传render_js还能传任何自定义数据。我要在列表页把标题先拎出来通过meta{title: ...}带到详情页这样详情页就不用重复解析一轮标题了。如果详情页也是JS渲染的我在静态解析发现数据缺失后会再发一次渲染请求同时把已经解析的item通过meta传递。这种“先静态试水失败再动态渲染”的降级策略非常实用避免所有页面都走Playwright毕竟浏览器渲染的耗时是普通请求的几十倍。4. 常见问题与排查技巧实录这部分我直接整理成速查表都是我真实碰到过的坑现象原因解决方案抓到的HTML全是空壳没有实际数据JS异步加载源码里没有内容启用Playwright中间件渲染后再解析BS4解析返回空列表selector没错页面结构改版class变了浏览器打开页面审查元素确认当前实际classPlaywright启动报错缺依赖库系统缺少Chromium运行库执行playwright install --with-deps chromium抓取速度太慢被目标站限流请求频率过高触发反爬调大DOWNLOAD_DELAY设置随机延迟数据库出现重复数据URL去重无法应对内容重复管道里加MD5指纹去重中文写入乱码编码识别错误在HtmlResponse里显式声明encodingutf-8iframe里面抓不到内容主文档和iframe不在同一帧用page.frames遍历定位目标frame抓取到一半IP被ban高频请求触发IP封禁降低并发、延长延迟、考虑代理池除了表里的问题还有几个排查思路想单独说。第一定位问题是解析层还是渲染层。一旦发现数据不对先手动用Playwright打开目标页面右键查看当前DOM结构。如果手动渲染后的HTML里有数据而response.text里没有那就是渲染层的问题如果两个都有但BS4解析不出来就是解析层selector的问题。分层排查不冤枉。第二针对iframe在浏览器控制台里执行window.frames.length查看帧数量。如果至少有2个frame说明数据极可能在iframe里。再用Performance面板或Network面板观察frame加载的URL找到准确的目标帧。第三Scrapy的日志是排查利器。把日志级别调成DEBUG能看到每一个请求的下载耗时、状态码。如果大量请求卡在一处不动大概率是页面加载超时考虑在中间件里加超时参数。5. 反爬应对与频率控制经验很多人一上来就急着上代理、上指纹浏览器实际上大部分站点根本用不上这些。反爬对抗是一个“按需升级”的过程一上来就重火力反而容易暴露。我通常按以下阶梯应对第一阶梯基础伪装。设置真实的User-Agent把Accept-Language加上中文DEFAULT_REQUEST_HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, }第二阶梯请求节奏控制。把并发降下来、延迟升上去。很多“被封”其实是自己把自己玩死的10个并发0延迟是个正常站点都会拉黑你。CONCURRENT_REQUESTS 4 DOWNLOAD_DELAY 2.0 RANDOMIZE_DOWNLOAD_DELAY True第三阶梯登录态与Cookie注入。需要登录才能看到的数据用Playwright手动登录一次导出Cookie再塞进请求。实际操作中我会写一个小脚本用Playwright打开页面、人工扫码或输密码然后序列化存储cookie。# 登录并保存cookies的脚本片段 with sync_playwright() as p: browser p.chromium.launch(headlessFalse) # 非无头模式方便人工登录 context browser.new_context() page context.new_page() page.goto(https://example.com/login) input(登录完成后按回车...) cookies context.cookies() with open(cookies.json, w) as f: json.dump(cookies, f)在Scrapy里加载这些Cookie就可以保持登录态抓取。注意Cookie是有时效的过期了要重新走一遍登录流程。第四阶梯代理池。这一步是最后的兜底手段不到万不得已不用。很多代理服务质量参差不齐反而降低抓取稳定性。如果确实需要优先选择全世界部署的住宅代理而不要用免费的公开代理——免费代理的IP段早就被目标站拉黑了用了等于白用。这里补充一个重要心法反爬对抗的核心是“让请求序列看起来像人”而不是“技术上碾压对方”。保持合理的抓取频率、不触发WAFWeb应用防火墙、不压垮对方服务器这是爬虫工程师的基本职业素养。技术方案之外,更要考虑如何与目标站点“和平共处”。6. 合规边界与个人经验谈最后这部分我想认真聊聊合规和边界问题这是每个做爬虫的人都绕不开的坎。第一robots协议是底线。虽然技术上可以无视robots.txt但我不建议这么做。robots.txt不仅是一个技术文件它更像一个“告示牌”告诉你这个站哪些区域欢迎爬虫、哪些区域不欢迎。尊重对方的意图是对自己和业务负责。第二个人隐私和受版权保护的内容坚决不碰。采集用户手机号、身份证号、私人聊天记录这类数据一旦采集并存储法律风险极高。采集新闻资讯标题和正文时也要谨慎处理版权。如果内容用于机器学习训练或商业分析建议使用官方API或授权数据源。第三频率控制就是自我保护。我见过太多人为了赶进度把并发调到50结果IP被封、服务器被警告、项目被迫暂停。合理的做法是按需调整频率观察目标站的负载能力不给对方造成压力。我在实际项目里的体会是技术实力决定了爬虫的“上限”但职业素养和边界意识决定了你能在这行走多远。刚入门的朋友可以先把代码水平练好但一定要从一开始就养成合规采集的习惯给自己少挖坑。数据抓取是门手艺活技术之外更考验人的判断力——什么时候该抓、什么时候该停、什么时候该找API这些远比多写几百行代码重要。希望这些经验能让你在爬虫这条路上少走些弯路。
Scrapy+BeautifulSoup+Playwright：复杂网页爬虫的黄金组合
做爬虫这行当久了你会发现一个很有意思的现象很多人把爬虫简单理解为“用代码把网页源码拉下来再拆拆字段”可真到了复杂场景——网页是JavaScript动态渲染的、目标数据藏在iframe里、网站反爬策略三天两头换——光靠一个库一把梭早就行不通了。今天我想聊的这套组合拳不是什么神秘黑科技而是我自己在实战里反复打磨出来的一套方案以Scrapy作为调度和抓取的骨架用BeautifulSoup负责页面解析和字段提取再在必要时引入Playwright处理动态渲染页面和iframe嵌套。这三大件各管一段配合得当几乎能覆盖日常工作中90%以上的抓取需求。这篇文章适合谁一是刚学完Python基础、准备上手爬虫的开发者二是已经用Scrapy写过简单爬虫、但一碰到动态页面就抓瞎的进阶用户。我会把从环境搭建、工程结构、核心解析逻辑到动态页面处理和反爬应对的完整链路都拆给你看里面不少细节是我踩过坑之后才悟出来的。1. 内容整体设计与思路拆解1.1 为什么是“BS4 Scrapy”而非单一框架先说个最常见的误区。不少人一上来就迷信Scrapy觉得它功能全、性能强什么页面都能搞定。实际上Scrapy最擅长的是“批量抓取 全站遍历”这类规模化任务它内置了调度器、去重队列、并发机制、中间件体系确实是重型武器。但它的短板也很明显页面的解析和字段提取写起来相对笨重尤其遇到那种结构混乱、没有规范class的HTML用Scrapy自带的Selector写XPath或CSS表达式能把人逼疯。反过来BeautifulSoup后文统称BS4在单页面解析上的体验极为顺手它容忍破损HTML的容错性极强配合lxml解析器之后查找元素、遍历节点、提取文本都非常直观。但BS4没有并发调度、没有请求去重、没有下载中间件你拿它写大规模爬虫最后一定会在自己写的“伪调度器”里翻车。所以我的方案是用Scrapy管“怎么抓、抓多少、怎么不重复抓”用BS4管“抓下来的页面怎么拆、字段怎么提”两者各自干自己最擅长的事。实力上不是替代关系而是互补关系。1.2 三层架构调度层、渲染层、解析层我在实际项目里把整个爬虫系统抽象成三层调度层Scrapy核心负责请求队列、并发控制、去重、重试、管道输出。这一层解决的是“批量稳定地拿回HTML”的问题。渲染层Playwright中间件解决动态渲染和iframe嵌套问题。网站数据如果是前端JS异步加载或者藏在多层iframe里直接请求URL拿到的HTML是残缺的必须用无头浏览器执行脚本后再取页面内容。解析层BS4负责从已经就绪的HTML里提取目标字段做数据清洗和结构化。这三层各管一头互不越界。最核心的设计心法是解析层绝不发请求调度层绝不碰HTML解析。很多新手写爬虫容易把代码糊成一团一个函数里既发请求又拆数据最后维护成本极高。分层的好处是任何一层出了问题只需要替换该层的实现不影响整体。1.3 这套组合能解决什么场景问题结合我接触过的实际需求这套组合主要覆盖以下几类场景新闻/资讯类采集页面结构相对规范但字段多、列表分页复杂BS4可以把标题、时间、正文、来源一次性提取干净。电商商品信息价格、库存、评价数量常藏在多级结构中部分字段需要进详情页二次抓取Scrapy的Request回调机制天然适配。数据报表类抓取不少管理系统把数据放在iframe里且需要登录态Playwright渲染层加上cookie注入就能搞定。JS强渲染的单页应用比如Vue/React写的前端页面纯请求拿不到数据必须走渲染层。一句话总结静态页用BS4爽快解析动态页用Playwright兜底渲染调度和去重全部交给Scrapy这就是这套组合的立身之本。2. 环境准备与工程搭建2.1 依赖安装与版本选择先把基础环境理清楚。我平时用Python 3.10/3.11强烈建议用虚拟环境别把依赖直接装到系统Python里。核心依赖就这么几个pip install scrapy beautifulsoup4 lxml playwright pymongo playwright install chromium几个依赖的定位说明一下scrapy主框架负责调度、下载、并发。beautifulsoup4HTML解析配lxml解析器速度最快容错也好。playwright无头浏览器专门应付JS动态渲染和iframe。不选Selenium是因为Playwright的API更现代自带wait机制处理动态元素比Selenium的time.sleep优雅太多。pymongo后文数据存储用MongoDB做持久化。安装完playwright后一定要执行playwright install chromium把浏览器内核下载下来。顺手装一下playwright install --with-deps chromium可以避免系统缺少动态库导致的启动崩溃。2.2 创建Scrapy项目与目录结构用Scrapy自带命令快速建项目scrapy startproject web_scraper cd web_scraper scrapy genspider news_spider example.com生成后的核心目录长这样web_scraper/ ├── scrapy.cfg ├── web_scraper/ │ ├── __init__.py │ ├── items.py # 数据模型定义 │ ├── middlewares.py # 下载中间件Playwright集成处 │ ├── pipelines.py # 数据处理管道清洗、去重、存储 │ ├── settings.py # 全局配置 │ ├── spiders/ │ │ └── news_spider.py我习惯把items.py当作数据模型定义文件。别小看这一步先定义好目标字段结构后面写Spider、写管道都会顺畅很多。比如我要抓资讯文章Item可以这样定义# web_scraper/items.py import scrapy class ArticleItem(scrapy.Item): title scrapy.Field() url scrapy.Field() source scrapy.Field() publish_time scrapy.Field() content scrapy.Field() tags scrapy.Field()2.3 Settings中的关键配置settings.py里有几个参数我必须提前说明因为直接关系到最后能不能稳定抓取# 爬虫优先级和并发设置 CONCURRENT_REQUESTS 8 DOWNLOAD_DELAY 1.0 RANDOMIZE_DOWNLOAD_DELAY True # 关闭默认去重使用自定义去重 DUPEFILTER_CLASS scrapy.dupefilters.RFPDupeFilter # 启用自定义中间件 DOWNLOADER_MIDDLEWARES { web_scraper.middlewares.PlaywrightMiddleware: 543, } # 启用管道 ITEM_PIPELINES { web_scraper.pipelines.MongoDBPipeline: 300, }DOWNLOAD_DELAY设成1.0秒是给目标网站减压顺带降低被封风险。RANDOMIZE_DOWNLOAD_DELAY让Scrapy在0.5到1.5倍之间随机波动延迟这让请求节奏更接近人工浏览。3. 核心实战融合抓取的完整链路3.1 用BS4解析静态页面定位、提取、清洗先看一个最基础的静态页面解析。在Spider的parse方法里拿到响应后直接用BS4处理# web_scraper/spiders/news_spider.py import scrapy from bs4 import BeautifulSoup from web_scraper.items import ArticleItem class NewsSpider(scrapy.Spider): name news_spider allowed_domains [example.com] start_urls [https://example.com/news] def parse(self, response): soup BeautifulSoup(response.text, lxml) # 定位列表区域的容器 article_list soup.select(div.news-list div.news-item) for article in article_list: item ArticleItem() # 标题优先取h2里的a标签文本 title_tag article.find(h2).find(a) if article.find(h2) else None item[title] title_tag.get_text(stripTrue) if title_tag else item[url] response.urljoin(title_tag[href]) if title_tag else # 摘要 desc_tag article.find(p, class_summary) item[content] desc_tag.get_text(stripTrue) if desc_tag else item[source] example.com # 分页找下一页链接 next_page soup.select_one(a.next) if next_page: yield scrapy.Request(response.urljoin(next_page[href]), callbackself.parse) yield item这里有几个细节我要特意强调第一get_text(stripTrue)是所有解析的标配。网页文本里塞满了空格、换行、\t如果不strip入库的数据全是脏的后面清洗代价更大。第二用response.urljoin处理相对链接。页面里href经常是/news/detail?id123这种相对路径直接存下来没意义。urljoin会基于当前页面URL自动拼接成完整地址。第三BS4的select和find混用是常态。分页导航这类结构清晰的地方用CSS选择器文章区域这种嵌套深、class多的情况用find链式查找更直观。两种方式互补不必纠结用哪个。第四注意空值保护。article.find(h2)返回None时链式调用会直接抛AttributeError。所以每一级查找都要做空值判断。我吃过这个亏抓几千条数据后程序崩溃排查半天才发现是某一篇文章少了h2标签。3.2 动态页面与iframePlaywright中间件的正确姿势静态页面的处理相对简单动态页面才是劝退大多数人的地方。这里的难题有两个一是数据是JS异步请求加载的直接请求URL返回的HTML没有数据二是数据被塞在iframe里主文档里压根看不到。我之前试过Selenium硬等time.sleep速度慢还容易误判加载完成。后来换了Playwright用显式等待替代固定等待稳定性提升了一个量级。我设计了一个下载中间件专门处理需要渲染的请求# web_scraper/middlewares.py from scrapy.http import HtmlResponse from playwright.sync_api import sync_playwright class PlaywrightMiddleware: 对需要JS渲染的请求执行Playwright浏览器渲染 def process_request(self, request, spider): # 如果没有开启渲染标记直接放行给Scrapy的默认下载器 if not request.meta.get(render_js): return None with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context( user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36, viewport{width: 1280, height: 800} ) page context.new_page() # 等待网络空闲比固定time.sleep靠谱 page.goto(request.url, wait_untilnetworkidle, timeout30000) # 处理iframe嵌套切换进入指定iframe取内容 # 更稳妥的做法递归查找所有iframe取src包含关键字或内容最丰富的那一层 target_frame None for frame in page.frames: if data in frame.url or content in frame.url: target_frame frame break if target_frame: target_frame.wait_for_selector(div.article-content, timeout10000) html target_frame.content() else: html page.content() browser.close() return HtmlResponse(urlrequest.url, bodyhtml, requestrequest, encodingutf-8)用的时候只需要在Spider的Request里带上meta{render_js: True}def parse_list(self, response): soup BeautifulSoup(response.text, lxml) for link in soup.select(a.article-link): yield scrapy.Request( urlresponse.urljoin(link[href]), callbackself.parse_detail, meta{render_js: True} )这里有几个教训第一等待条件选networkidle不一定最优。如果页面里一直有轮询请求networkidle可能永远等不到最后超时。遇到这种页面我建议换成domcontentloaded然后针对目标元素做wait_for_selector等组件出现才是真正的准。第二page.frames里包含主文档和所有iframe。主文档的frame.url是当前页面地址iframe有各自独立的URL。判断哪个iframe才是目标不能靠猜要结合URL关键字或页面内容特征。我踩过的坑是页面里有三个iframe两个是广告一个才是数据区一开始没做过滤抓回来全是广告内容。第三同步API还是异步API的选择。Playwright同时提供sync_playwright和async_playwright。Scrapy的下载中间件是同步调用模型用sync_playwright足够代码也容易理解。没必要为了“性能”强行上异步复杂度上去了收益却有限。3.3 Item Pipeline数据清洗、去重与入库解析层提取的原始数据通常不能直接用需要在管道里做二次处理。我习惯把Pipeline拆成三个环节清洗、去重、存储。先看清洗管道的写法# web_scraper/pipelines.py import re from pymongo import MongoClient class DataCleanPipeline: 字段清洗去空格、去HTML标签、格式化时间 def process_item(self, item, spider): # 标题清洗 if item.get(title): item[title] re.sub(r\s, , item[title]).strip() # 正文清洗去掉多余空白符 if item.get(content): item[content] re.sub(r\n\s*\n, \n, item[content]).strip() # 时间统一成ISO格式 if item.get(publish_time): # 实际根据目标站点的格式写正则匹配 item[publish_time] item[publish_time].replace( 年, -).replace(月, -).replace(日, ) return item清洗完成后是去重。Scrapy自带基于URL的去重但很多时候URL不同、内容相同。比如带参数的重定向URL或者一稿多发。这种场景我建议加一层基于标题MD5指纹的去重import hashlib class DuplicatesPipeline: 基于标题指纹的重复检查 def __init__(self): self.seen set() def process_item(self, item, spider): title item.get(title, ) fingerprint hashlib.md5(title.encode(utf-8)).hexdigest() if fingerprint in self.seen: raise DropItem(f重复内容: {title}) self.seen.add(fingerprint) return itemraise DropItem是Scrapy管道里最实用的技巧之一。它能在管道中途丢弃数据后面所有管道都不会执行自然也不会入数据库。这个机制比返回None再判断要干净得多。最后是MongoDB存储class MongoDBPipeline: def __init__(self, mongo_uri, mongo_db): self.mongo_uri mongo_uri self.mongo_db mongo_db self.client None self.db None classmethod def from_crawler(cls, crawler): return cls( mongo_uricrawler.settings.get(MONGO_URI, mongodb://localhost:27017), mongo_dbcrawler.settings.get(MONGO_DATABASE, spider_data) ) def open_spider(self, spider): self.client MongoClient(self.mongo_uri) self.db self.client[self.mongo_db] def close_spider(self, spider): self.client.close() def process_item(self, item, spider): collection self.db[spider.name] collection.insert_one(dict(item)) return item注意from_crawler这个类方法。它能让Pipeline从settings.py里读取配置这是Scrapy官方推荐的方式。千万别写死在代码里否则换环境部署、换数据库地址的时候要改源码太折腾了。3.4 爬虫主逻辑列表页与详情页的衔接一个稍微复杂点的场景是列表页给摘要和链接详情页给正文。这需要Scrapy的请求回调机制来串联。我把常见的写法拆解一下class NewsSpider(scrapy.Spider): name news_spider allowed_domains [example.com] start_urls [https://example.com/news] def parse(self, response): soup BeautifulSoup(response.text, lxml) for link in soup.select(div.news-list a.article-link): yield scrapy.Request( urlresponse.urljoin(link[href]), callbackself.parse_detail, meta{title: link.get_text(stripTrue)} ) # 翻页 next_page soup.select_one(a.next-page) if next_page: yield scrapy.Request( urlresponse.urljoin(next_page[href]), callbackself.parse ) def parse_detail(self, response): soup BeautifulSoup(response.text, lxml) item ArticleItem() # meta里的数据直接继承 item[title] response.meta.get(title, ) item[url] response.url content_div soup.find(div, class_article-detail) if content_div: # get_text提取所有段落文本 分隔避免粘在一起 item[content] content_div.get_text(separator , stripTrue) # 动态详情页标记渲染需求 if soup.find(div, idjs-content) is None: yield scrapy.Request( urlresponse.url, callbackself.parse_detail_dynamic, meta{render_js: True, item: item} ) else: yield item这里有个细节meta参数除了能传render_js还能传任何自定义数据。我要在列表页把标题先拎出来通过meta{title: ...}带到详情页这样详情页就不用重复解析一轮标题了。如果详情页也是JS渲染的我在静态解析发现数据缺失后会再发一次渲染请求同时把已经解析的item通过meta传递。这种“先静态试水失败再动态渲染”的降级策略非常实用避免所有页面都走Playwright毕竟浏览器渲染的耗时是普通请求的几十倍。4. 常见问题与排查技巧实录这部分我直接整理成速查表都是我真实碰到过的坑现象原因解决方案抓到的HTML全是空壳没有实际数据JS异步加载源码里没有内容启用Playwright中间件渲染后再解析BS4解析返回空列表selector没错页面结构改版class变了浏览器打开页面审查元素确认当前实际classPlaywright启动报错缺依赖库系统缺少Chromium运行库执行playwright install --with-deps chromium抓取速度太慢被目标站限流请求频率过高触发反爬调大DOWNLOAD_DELAY设置随机延迟数据库出现重复数据URL去重无法应对内容重复管道里加MD5指纹去重中文写入乱码编码识别错误在HtmlResponse里显式声明encodingutf-8iframe里面抓不到内容主文档和iframe不在同一帧用page.frames遍历定位目标frame抓取到一半IP被ban高频请求触发IP封禁降低并发、延长延迟、考虑代理池除了表里的问题还有几个排查思路想单独说。第一定位问题是解析层还是渲染层。一旦发现数据不对先手动用Playwright打开目标页面右键查看当前DOM结构。如果手动渲染后的HTML里有数据而response.text里没有那就是渲染层的问题如果两个都有但BS4解析不出来就是解析层selector的问题。分层排查不冤枉。第二针对iframe在浏览器控制台里执行window.frames.length查看帧数量。如果至少有2个frame说明数据极可能在iframe里。再用Performance面板或Network面板观察frame加载的URL找到准确的目标帧。第三Scrapy的日志是排查利器。把日志级别调成DEBUG能看到每一个请求的下载耗时、状态码。如果大量请求卡在一处不动大概率是页面加载超时考虑在中间件里加超时参数。5. 反爬应对与频率控制经验很多人一上来就急着上代理、上指纹浏览器实际上大部分站点根本用不上这些。反爬对抗是一个“按需升级”的过程一上来就重火力反而容易暴露。我通常按以下阶梯应对第一阶梯基础伪装。设置真实的User-Agent把Accept-Language加上中文DEFAULT_REQUEST_HEADERS { User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/119.0.0.0 Safari/537.36, Accept: text/html,application/xhtmlxml,application/xml;q0.9,*/*;q0.8, Accept-Language: zh-CN,zh;q0.9,en;q0.8, }第二阶梯请求节奏控制。把并发降下来、延迟升上去。很多“被封”其实是自己把自己玩死的10个并发0延迟是个正常站点都会拉黑你。CONCURRENT_REQUESTS 4 DOWNLOAD_DELAY 2.0 RANDOMIZE_DOWNLOAD_DELAY True第三阶梯登录态与Cookie注入。需要登录才能看到的数据用Playwright手动登录一次导出Cookie再塞进请求。实际操作中我会写一个小脚本用Playwright打开页面、人工扫码或输密码然后序列化存储cookie。# 登录并保存cookies的脚本片段 with sync_playwright() as p: browser p.chromium.launch(headlessFalse) # 非无头模式方便人工登录 context browser.new_context() page context.new_page() page.goto(https://example.com/login) input(登录完成后按回车...) cookies context.cookies() with open(cookies.json, w) as f: json.dump(cookies, f)在Scrapy里加载这些Cookie就可以保持登录态抓取。注意Cookie是有时效的过期了要重新走一遍登录流程。第四阶梯代理池。这一步是最后的兜底手段不到万不得已不用。很多代理服务质量参差不齐反而降低抓取稳定性。如果确实需要优先选择全世界部署的住宅代理而不要用免费的公开代理——免费代理的IP段早就被目标站拉黑了用了等于白用。这里补充一个重要心法反爬对抗的核心是“让请求序列看起来像人”而不是“技术上碾压对方”。保持合理的抓取频率、不触发WAFWeb应用防火墙、不压垮对方服务器这是爬虫工程师的基本职业素养。技术方案之外,更要考虑如何与目标站点“和平共处”。6. 合规边界与个人经验谈最后这部分我想认真聊聊合规和边界问题这是每个做爬虫的人都绕不开的坎。第一robots协议是底线。虽然技术上可以无视robots.txt但我不建议这么做。robots.txt不仅是一个技术文件它更像一个“告示牌”告诉你这个站哪些区域欢迎爬虫、哪些区域不欢迎。尊重对方的意图是对自己和业务负责。第二个人隐私和受版权保护的内容坚决不碰。采集用户手机号、身份证号、私人聊天记录这类数据一旦采集并存储法律风险极高。采集新闻资讯标题和正文时也要谨慎处理版权。如果内容用于机器学习训练或商业分析建议使用官方API或授权数据源。第三频率控制就是自我保护。我见过太多人为了赶进度把并发调到50结果IP被封、服务器被警告、项目被迫暂停。合理的做法是按需调整频率观察目标站的负载能力不给对方造成压力。我在实际项目里的体会是技术实力决定了爬虫的“上限”但职业素养和边界意识决定了你能在这行走多远。刚入门的朋友可以先把代码水平练好但一定要从一开始就养成合规采集的习惯给自己少挖坑。数据抓取是门手艺活技术之外更考验人的判断力——什么时候该抓、什么时候该停、什么时候该找API这些远比多写几百行代码重要。希望这些经验能让你在爬虫这条路上少走些弯路。
