Playwright电商动态数据采集实战：从接口监听到DOM解析

干爬虫这行的都知道现在真正让人头疼的不是那些静态页面而是像电商百亿补贴、秒杀会场这种页面——价格是 JS 动态算出来的列表是滚动加载的数据是接口加密返回的。你用requests去请求拿回来的 HTML 基本就是个空壳里面除了框架啥都没有。我刚入门那会儿也在这上面栽过跟头盯着抓包工具里那个返回 JSON 的接口看了半天却发现直接请求它根本拿不到完整数据不是报参数错误就是返回乱码。后来换了思路干脆不跟接口死磕了直接上 Playwright 这种浏览器自动化工具。你要什么数据就让真实浏览器帮你打开页面等它渲染完了你直接去页面里取。思路说起来就一句话requests 是打电话问客服Playwright 是找个真人代购去商场里把每件商品的标签拍下来给你。这篇文章我把自己在电商动态商品数据采集上的完整经验梳理了一遍从环境搭建、数据提取方案、入库到常见坑位排查都有适合刚接触 Playwright 的爬虫新手也适合用 selenium 一直写不顺、想换工具的老手。1. 为什么 requests 搞不定偏偏要上 Playwright1.1 电商页面早就不再是纯 HTML 了很多读者可能不知道现在的电商页面和你十年前看的不一样了。十年前你requests.get一个商品列表页服务器直接吐出一大段完整的 HTML商品名称、价格、图片全在里面躺着你用正则或者 BeautifulSoup 直接就能打捞出数据。现在呢页面是个 SPA单页应用服务端只返回一个 HTML 骨架和一堆 JS 文件。浏览器加载完骨架之后再执行 JS去请求后端接口拿到 JSON 数据最后把数据渲染到页面上。你直接curl那个 URL看到的大概率是div idapp/div这种空壳。而且电商平台的反爬体系早就不是简单检查 User-Agent 了它们会在接口层面做签名校验、行为验证。你在浏览器里看到的每个商品价格都是前端用一串你看不懂的加密参数向服务端换来的。就算你把接口 URL 找出来了缺了那几个动态生成的参数也很难直接调用成功。所以这时候你需要的是一个“能完整执行 JS、能模拟真实用户操作、能等待异步数据渲染完成”的浏览器环境。这就是浏览器自动化工具的核心价值。1.2 Playwright 到底解决了什么问题Playwright 是微软开源的一个浏览器自动化框架支持 Chromium、Firefox、WebKit 三种内核。和 Selenium 相比它有几个很实用的优势。第一是自动等待机制。Selenium 里你经常要自己写time.sleep或者WebDriverWait去等元素出现Playwright 直接提供了wait_for_selector、expect_response这类内置方法它内部会持续轮询 DOM 树直到目标元素出现或者超时不需要手动猜要等多久。第二是原生支持网络监听。这个功能对爬虫来说太好用了。你可以用page.on(response)监听页面发出的所有 HTTP 请求直接把 JSON 接口的响应体截获下来。这种方式比解析 DOM 稳定得多后面我会专门展开讲。第三是上下文隔离。你可以用browser.new_context()创建多个相互独立的浏览器环境每个 context 有自己的 Cookie、缓存、User-Agent很方便做多账号、多环境的切换。我自己的感受是用 Playwright 写爬虫代码量大概只有 Selenium 的三分之二而且调试成本低。很多在 Selenium 里反复踩的坑——比如元素被遮挡、iframe 定位不到、弹窗挡路——在 Playwright 里都有对应的原生 API 帮你处理。1.3 适合与不适合用 Playwright 的场景说句实在话Playwright 不是万能的用之前你要先判断场景到底适不适合。适合的场景有三个。第一页面数据靠异步加载直接请求拿不到内容第二目标站点有登录验证、滑块、行为检测你需要用真实浏览器环境来“伪装”成正常用户第三你需要模拟复杂的用户操作比如滚动、点击、切换标签页才能触发数据加载。不适合的场景也有三个。第一目标接口参数简单、无加密直接用requests加一个合理的User-Agent就能拿到 JSON那就别多此一举开浏览器了又慢又耗资源。第二你需要每天定时跑几百万条数据浏览器自动化的性能和稳定性都撑不住这个量级应该考虑排队请求接口或者寻找更合规的数据渠道。第三目标站点的风控系统很敏锐对无头浏览器识别得很准频繁请求容易触发封禁这时候不管你用什么工具都白搭。选择工具的底层逻辑是成本requests最轻代价是拿不到动态数据Playwright 最重但能在动态渲染场景下拿到数据。你要做的是先判断页面复杂度再决定用什么工具而不是无条件上重武器。2. 动手前的准备环境搭建与浏览器内核2.1 Python 环境与依赖安装我的开发环境是 Python 3.10版本建议至少 3.9 以上因为 Playwright 的新版本对低版本 Python 支持越来越弱了。安装过程非常简单两条命令搞定pip install playwright playwright install chromium第一条命令装的是 Python 库第二条命令会把 Chromium 浏览器内核下载到本地。这里要提醒你一句首次执行playwright install时下载量大概是 150MB 左右如果网络状况一般建议给 pip 配个国内镜像源pip install playwright -i https://pypi.tuna.tsinghua.edu.cn/simple装完先跑一个最简单的小脚本验证环境是否正常from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessFalse) page browser.new_page() page.goto(https://example.com) print(page.title()) browser.close()看到终端输出Example Domain就说明环境没问题了。headlessFalse表示有头模式你能看到一个真实的浏览器窗口打开和关闭headlessTrue则是无头模式适合服务器上跑。2.2 浏览器内核怎么选Playwright 支持三种浏览器内核我建议默认用 Chromium因为它跟 Chrome 的渲染引擎一致页面兼容性最好。Firefox 和 WebKit 在自动化场景下渲染效果和 API 行为大致相同但如果碰到某些依赖 Chrome 特性的页面就可能出幺蛾子。另外有一个容易被忽略的小细节p.chromium.launch()默认用的是一种特殊的自动化 Chromium 版本和你日常用的 Chrome 不一定完全一样。如果你的脚本在自动化浏览器里没问题但怀疑目标网站的检测机制会识别navigator.webdriver这类特征可以考虑用channelchrome参数去调用你本机安装的 Chromebrowser p.chromium.launch(channelchrome, headlessFalse)这样 Playwright 会直接复用你本机的 Chrome 程序浏览器指纹更接近真实用户。这个不是破解什么高深反爬只是降低被识别为自动化程序的概率纯属技术层面的优化。2.3 给脚本加一个“降速阀”写爬虫最忌讳的就是脚本跑得像机器一样匀速、稳定、毫秒不差。真实用户不可能每 2 秒点一次页面也不可能每 30 分钟刷新一次列表这种机械感最容易触发平台的行为监控。我习惯在关键操作之间加随机延时import random import time def human_delay(min_sec0.8, max_sec2.5): time.sleep(random.uniform(min_sec, max_sec))然后在每次点击、滚动、翻页之后调用human_delay()。别小看这个随机延时它能大幅降低请求频率的规律性。还有一个经验值是单页面的整体执行节奏控制在 8 到 15 秒之间太慢了太浪费时间太快了又不符合真人浏览习惯。3. 核心实现三招拿下动态商品数据这一节是整个文章的重头戏。我把自己常用的三种数据提取方案全部列出来分别应对不同的情况。实际项目中我一般是先看包能抓接口就不解析 DOM接口抓不到或者加密太复杂再退回 DOM 解析。3.1 方案一监听网络响应直接抓 JSON 接口这是我最推荐的方式没有之一。原理很简单浏览器里加载页面时前端 JS 会主动请求后端接口拿到 JSON 数据后渲染成 DOM。既然 JSON 数据本来就会经过浏览器那我们在 Playwright 里监听所有网络响应把那些接口返回的 JSON 直接截获下来就行。我经常用一个辅助函数来统一处理响应监听from playwright.sync_api import sync_playwright captured_data [] def handle_response(response): if /api/ in response.url and response.status 200: try: json_data response.json() except Exception: return # 只保留我们关心的数据避免把乱七八糟的埋点接口也存下来 if product in response.url or goods in response.url: captured_data.append(json_data) with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.on(response, handle_response) page.goto(https://目标站点/百亿补贴, wait_untilnetworkidle) # 页面加载完成后多滚动几次触发接口重新请求 for _ in range(5): page.mouse.wheel(0, 1200) page.wait_for_timeout(1500) browser.close()这段代码的核心就一个page.on(response, handle_response)。它会捕获页面里所有的 HTTP 响应包括 XHR、Fetch、静态资源等。你在handle_response里过滤 URL 关键字解析 JSON取你需要的数据。有读者会问怎么判断哪个接口是商品数据接口很简单打开浏览器开发者工具的Network面板手动打开目标页面在筛选框里输入XHR或者Fetch然后看哪个请求返回的数据里包含商品名称、价格。找到那个请求记下它的 URL 特征写进过滤条件里就行。这个方法比解析 DOM 稳在哪DOM 结构会因为前端改版而频繁变动今天classprice明天就变成classprc你的选择器就废了。接口 JSON 的字段结构在正常迭代下会稳定得多而且返回的数据字段更全除了页面展示的还有商品 ID、活动 ID、优惠类型这些利索数据。拿来做数据分析或者二次处理体验完全不是一个量级。3.2 方案二直接解析渲染后的 DOM如果目标站点的接口做了很强的加密监听响应也拿不到明文 JSON那就得退回 DOM 解析方案。这个方案其实也很成熟用 Playwright 打开页面等待数据渲染完成后通过选择器批量提取文本和属性。核心代码长这样with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://目标站点/list, wait_untilload) # 等待商品卡片出现最多等 10 秒 page.wait_for_selector(.product-card, timeout10000) # 获取所有商品名称 titles page.locator(.product-card .title).all_text_contents() # 获取所有价格文本 prices page.locator(.product-card .price).all_text_contents() # 获取所有商品链接 links page.locator(.product-card a).evaluate_all( elements elements.map(e e.href) ) for i in range(len(titles)): print(titles[i], prices[i], links[i])这里有两个容易踩的坑。第一个是不要用page.inner_text(.product-card)这种把整个卡片文本一把抓的方式。因为你没法保证每个卡片的字段顺序一致商品名称里如果混了促销标签数据会很脏。建议一个字段一个选择器分开提取最后按索引拼装。第二个是滚动加载的页面要循环滚动几次。现在的电商列表基本都是无限滚动页面初始只会加载一屏数据你得通过滚动触发后续加载previous_count 0 for _ in range(20): page.mouse.wheel(0, 1200) page.wait_for_timeout(1200) current_count page.locator(.product-card).count() if current_count previous_count: break previous_count current_count这段代码的逻辑是每次滚动后统计商品卡片数量如果连续两次数量没变化说明已经到底了直接跳出循环。这样写比较稳不会出现“滚动次数不够导致漏数据”或者“滚动过多次浪费时间”的问题。3.3 方案三接管登录态带着 Cookie 访问电商平台很多数据都需要登录才能看完整比如商品的真实成交价、历史价格、库存数量。这时候每次启动浏览器都扫码登录显然不现实所以我一般用 Playwright 的storage_state机制把登录状态持久化保存。第一步手动操作一次登录with sync_playwright() as p: browser p.chromium.launch(headlessFalse) context browser.new_context() page context.new_page() page.goto(https://目标站点/login) # 手动扫码或者输入账号登录登录成功后停留几秒等 Cookie 稳定 page.wait_for_timeout(5000) # 保存登录状态到本地文件 context.storage_state(pathstate.json) browser.close()第二步下次脚本启动时直接加载登录态with sync_playwright() as p: browser p.chromium.launch(headlessTrue) context browser.new_context(storage_statestate.json) page context.new_page() # 现在访问需要登录的页面直接就是登录状态 page.goto(https://目标站点/cart)为什么用storage_state而不是直接在代码里塞 Cookie因为storage_state不仅保存了 Cookie还把localStorage、sessionStorage里的内容也一并保存了。很多站点的登录态有一部分存在localStorage里你只复制 Cookie 是没用的。这就好比别人给你一个钥匙但你进小区还要刷门禁卡而storage_state是把钥匙和门禁卡给你一起打包了。还要提醒一句登录状态文件不要提交到 Git 仓库里去里面带着你的账号凭证泄露了是可以被别人冒用的。我在项目里都会把state.json加进.gitignore。3.4 数据清洗与入库SQLAlchemy 版数据抓下来只是第一步后续的存储、去重、分析才是关键。我一般用 SQLAlchemy 入库因为它能让我用 Python 类定义表结构不用手写 SQL后续增删改查也很顺手。一个简单的商品表定义from sqlalchemy import create_engine, Column, String, Float, Integer, DateTime from sqlalchemy.orm import declarative_base, sessionmaker from datetime import datetime Base declarative_base() class Product(Base): __tablename__ products id Column(Integer, primary_keyTrue, autoincrementTrue) product_id Column(String(64), uniqueTrue, indexTrue) title Column(String(512)) price Column(Float) original_price Column(Float) sales Column(Integer) shop_name Column(String(256)) url Column(String(1024)) created_at Column(DateTime, defaultdatetime.now) engine create_engine(mysqlpymysql://user:passwordlocalhost/ecommerce?charsetutf8mb4) Base.metadata.create_all(engine) Session sessionmaker(bindengine)插入数据时利用product_id的唯一约束做去重def save_products(products): session Session() try: for p in products: existing session.query(Product).filter_by(product_idp[product_id]).first() if existing: existing.price p[price] existing.sales p[sales] else: session.add(Product(**p)) session.commit() except Exception: session.rollback() raise finally: session.close()这个save_products函数走的是“存在则更新不存在则插入”的逻辑。爬虫跑多轮之后数据不会无限膨胀价格和销量始终保持最新状态这个对后续做价格趋势分析特别有用。补充一点如果你只是临时分析、不需要长期存储直接用csv模块写 CSV 文件就够了别动不动就上数据库数据和复杂度不一定匹配。4. 动态页面三大坑弹窗、滚动加载与 iframe4.1 弹窗与浮层脚本被卡住的第一杀手电商页面的弹窗是真多。新人首单红包、优惠券领取、签到提醒、地理位置授权任何一个弹窗糊住页面你的定位点击就会失准数据提取也可能拿不到完整内容。我的处理习惯是先尝试点击关闭按钮点击不到就按Esc键兜底def close_popups(page): # 尝试点击常见关闭按钮 for selector in [.close, .icon-close, [aria-label关闭], .pop-close]: try: if page.locator(selector).first.is_visible(): page.locator(selector).first.click() page.wait_for_timeout(500) return except Exception: continue # 兜底方案按 Esc page.keyboard.press(Escape)这段代码我会放在每次页面加载完成之后、数据提取之前的缝隙里。有人可能会问为什么不直接禁用弹窗里的某些元素因为弹窗是动态渲染出来的你很难在初始化阶段阻止它加载关闭按钮先点了再说是最省事的办法。其实这里还有个小技巧如果弹窗只在第一次访问时出现你可以把看到弹窗登录完之后的storage_state保存下来下次启动时直接用登录态很多“新手引导型”弹窗就不会出现了。4.2 无限滚动与列表懒加载漏数据的万恶之源列表页的懒加载机制是写爬虫时最容易漏数据的地方。页面从一开始只加载一部分商品你往下滚它才去请求下一批。问题在于你不能确定什么时候滚到底了。我前面 3.2 节给了一个“统计卡片数量”的方案这里再补充一个更严谨的做法通过接口计数来判断。如果你用的是监听响应方案可以在handle_response里加一个计数器每捕获一个商品列表接口的响应就自增一次。当连续多次滚动后这个计数器不再变化说明没有新的数据请求发出来基本就到底了。如果用的是 DOM 解析方案建议设置一个最大滚动次数上限。假设商品总数 1000 条每批加载 40 条按 30 批计算循环滚 35 次还没到底就有问题了。设置一个上限可以防止脚本死循环滚一整天这是我在实际项目里踩过坑才补上的保护机制。4.3 iframe 与多标签页定位不到元素的元凶现在有不少电商页面会在主页面里嵌入 iframe 来实现某个独立功能模块登录框、支付面板、客服聊天这类组件尤其常见。Playwright 针对 iframe 有专门的处理方式# 获取 iframe 内部的元素 frame page.frame_locator(iframe[src*login]) frame.locator(#username).fill(your_account) frame.locator(#password).fill(your_password) frame.locator(.submit-btn).click()还有一个场景是点击某个链接后新标签页自动打开数据在那个新页面里。这时候你要切换 page 对象with page.expect_popup() as popup_info: page.click(.open-new-page-button) new_page popup_info.value new_page.wait_for_load_state() # 之后的操作都在 new_page 上进行如果你不切换 page继续在新 page 上调用选择器就会报“元素找不到”的错误。多标签页切换是 Playwright 爬虫里比较容易忽略的坑报错信息还不明显得靠经验判断。4.4 反爬检测的几个信号做爬虫这行绕不开反爬这个话题。我不打算教你怎么绕过风控系统但有些现象你要能识别知道它发生了才能做出正确判断。常见信号包括页面提示“网络异常”“访问过于频繁”、验证码频繁弹出、数据字段出现乱码、接口返回空数组、同一个 Cookie 访问被限流。一旦脚本出现这些情况最正确的处理不是继续调参重试而是立即暂停脚本降低频率或者换个时段再跑。我见过太多新手在触发反爬之后不死心调头去研究什么高深反爬算法结果账号被封、IP 被封最后连正常数据都拿不到。爬虫的本质是“协商式访问”你太贪婪服务器就会拒绝你。学会克制频率、控制节奏、非必要不采集在这个领域反而是一种核心竞争力。5. 常见问题排查实录这里分享几个我在实际跑 Playwright 爬虫过程中反复遇到的经典问题整理成速查表直接对照排查。问题现象可能原因排查与解决wait_for_selector超时页面登录态失效、二次跳转、异步组件加载过慢检查是否被重定向到登录页增加超时时间到 15 秒用wait_untilnetworkidle替代默认加载状态提取到的数据有整段缺失弹窗遮挡、 lazy-load 图片占位、列表未滚动到底先调close_popups()关弹窗强制滚动到底后再提取观察浏览器控制台有没有报 JS 错误数据重复无限滚动触发了重复请求、分页参数错乱入库前用product_id做唯一性去重检查是否多次保存了同一个响应内存占用越来越大长时间跑一个 browser 实例、context 未释放周期性重启浏览器进程每个批次任务创建独立 context执行完context.close()页面白屏本地缓存脏数据、浏览器版本和站点不兼容开启无痕模式new_context()时不复用 storage_state升级 Playwright 版本换channelchrome代码能跑但数据永远为空接口 URL 过滤条件错误、响应是加密 JSON在handle_response里把匹配到的 URL 全部打印出来人工确认数据接口的真实地址我重点说一下第二行的“提取到的数据有整段缺失”这个问题。新手最容易把它当成选择器写错了疯狂调整class名称。但真正的罪魁祸首往往是图片懒加载页面只在商品卡片可见时才加载图片和附属数据你没滚动到那一屏那部分的 DOM 节点是占位符根本没有文本内容你当然提取不到。解决办法就是多滚动滚到每个商品都真实渲染出来再去提取。还有那个“内存占用越来越大”的问题这个是长任务跑久了几乎必然出现的。浏览器内核本身就是内存大户再加上多个 context、事件监听器、缓存跑个几小时轻轻松松吃掉你几个 G 内存。我的做法是写一个“每 N 个页面重启一次浏览器”的调度逻辑在重试框架外层把 browser 关掉再重新launch虽然听起来粗暴但实操中比各种精细调优都有效。6. 最后说几句合规与经验爬虫写多了以后我对“能不能爬”这个问题有了更深的理解。技术能力只是前提边界意识才是决定你能不能长期做这行的关键。我的原则是只采集公开可见的数据只用于个人学习或数据分析不碰用户隐私、不抓交易记录、不批量下载受版权保护的内容。采集频率控制在对目标站点影响最小的水平每个任务跑完主动歇一歇给服务器留出喘息时间。尊重robots.txt虽然它只是君子协定技术上一千种办法绕过但遵守它是从业底线。实操中还有一个特别值得说的经验不要执着于让一个脚本一次性解决所有问题。我之前为了抓一个复杂页面的数据连续调了三天脚本后来发现把采集拆成“抓列表→抓详情→存库”三个阶段每个阶段独立跑、中间用数据表拼接反而简单得多出了问题也好排查。工程化思维在爬虫领域同样适用这是很多自学爬虫的朋友容易忽略的。如果你准备把这套方案用在自己的项目上我建议从监听接口那个方案开始写数据结构最干净后续处理最省事。遇到接口加密再退到 DOM 解析灵活切换不要一条路走到黑。最后还是要再说一遍合法合规使用技术、尊重平台规则才能让爬虫这条路走得长远。