★ FEATURED ARTICLE 做爬虫有些年头大家最初接触的都是 requests BeautifulSoup 这套组合拳静态页面抓得飞起。等到需求一变要求采集那些依赖 JavaScript 动态渲染的页面时很多人就会卡住——直接请求拿回来的 HTML 是空的或者只有个空壳子骨架。这种问题我在带新人时见得太多了新手最容易卡在这里明明浏览器里能看到数据代码里却怎么都抓不到。Playwright 就是用来解决这类问题的工具。它本质上是浏览器自动化框架能真正打开一个浏览器内核去加载页面、执行 JS、等待网络请求完成然后我们再把渲染完成后的完整 HTML 拿回来或者直接截图看现场。这次实战项目第 11 节的核心就是围绕两个关键词展开渲染后的 HTML 到底怎么稳定拿到以及遇到诡异问题时如何用截图定位。这两个能力学透了动态页面的爬取思路基本就通了。这篇内容适合三类人刚学完 requests 基础、开始碰动态页面的新手已经会用 Selenium 但觉得维护成本高、想换工具的老手还有那些正在被反爬和渲染等待问题折磨的采集开发。我会把从环境搭建到实操落地的完整过程踩过的每个坑都摊开讲清楚。1. 为什么 requests 拿不到数据而 Playwright 可以1.1 关键区别拿到的是静态骨架而非真实页面很多人第一次遇到动态页面时第一反应是检查自己的请求头是不是少了参数或者是 Cookie 没带全。实际上requests 拿不到数据的原因通常很单纯目标页面的数据根本不在初始 HTML 里。现代前端框架包括但不限于 Vue、React 这类主流方案的典型工作方式是服务器只返回一个 div 壳子然后浏览器加载一堆 JS 文件这些 JS 再向后端接口发请求拿到 JSON 数据之后在前端把 DOM 节点一个个创建出来。整个过程在浏览器里是毫秒级完成但我们用 requests 模拟的是“还没有执行 JS”的状态自然只能拿到空壳。我用一个生活化类比来解释requests 相当于你站在店门口看橱窗里的菜单但菜是后厨现做的你光看菜单不看后厨永远不知道今天的招牌菜是什么。而 Playwright 相当于走进店里坐下等服务员把菜端上桌你看到的就是完整的、真实的菜品。这个区别决定了技术选型。如果你的目标页面数据藏在接口里F12 能找到 JSON 接口那优先用 requests 直连接口效率最高。如果接口加密、参数混淆严重、数据散落在多次异步请求中那就让 Playwright 直接上浏览器用“所见即所得”的思路绕过复杂的接口分析。1.2 Playwright 方案的核心优势与选型理由在浏览器自动化这个领域Playwright 不是第一个但综合体验确实是比较能打的。对比同类工具它有几点在实际项目中让我觉得特别顺手第一自带等待机制。它不是死等固定秒数而是会自动等待元素出现、网络请求空闲这套机制能把“不确定性”大幅降低。我在实战中最直观的感受就是同样一个页面用固定 sleep 的方案时不时报错换成 Playwright 的等待策略之后稳定很多。第二自动处理浏览器下载。你只需要一条命令它就能把对应版本的浏览器内核下载好不用像某些老牌工具那样手工配置驱动、再费劲处理版本不匹配的问题。新手在这块省的折腾时间真的很可观。第三截图和调试能力非常强。支持全页截图、元素截图、局部截图还能把操作过程录制成视频。这对于排查“为什么我这个元素没抓到”的问题价值极高。这次的实战项目把截图定位作为一节重点很大原因就是它真的能救命。第四支持多种浏览器内核。Chromium、Firefox、WebKit 都能跑某些场景下换内核能规避极端的环境差异问题。这套方案也不是没有缺点。它比纯 requests 方案要吃资源跑起来需要真实的浏览器进程对服务器内存有要求。多并发场景如果没控制好服务器容易吃紧。但作为动态页面采集的兜底方案Playwright 的性价比在同类工具里确实是很划算的。2. 环境搭建与第一个可用脚本2.1 安装步骤与常见出错点安装这块我记得最深的是新手最容易卡在浏览器内核下载这一步。如果你把网络环境限制得很严或者下载源不可用这一步极有可能失败。常规步骤是两层pip install playwright playwright install chromium第一层安装的是 Python 库本身第二层才是在本地下载 Chromium 浏览器内核。很多人在第一步成功后第二步报错或者卡住就开始怀疑人生。这里要说明一个很关键的认知playwright这个 Python 包本身不含浏览器它只是控制层真正干活的是内核。所以两步都成功环境才算真正就绪。如果第二步下载缓慢或失败通常会建议配置镜像源或者在网络条件允许的情况下重试。还有一种很多人不知道的方式playwright install --with-deps chromium可以在安装内核的同时装好依赖库Linux 服务器场景下特别有用少了这一步运行时会莫名报缺少动态库的错误。2.2 最小可用脚本与同步 API 初体验环境装好后我建议先跑一个最小脚本验证整套链路是否通畅from playwright.sync_api import sync_playwright with sync_playwright() as p: browser p.chromium.launch(headlessTrue) page browser.new_page() page.goto(https://example.com, timeout60000) html page.content() print(len(html)) browser.close()这里有几个新手需要重点理解的地方sync_playwright()是一个上下文管理器它管理着浏览器驱动的整个生命周期。这里用的是同步 API写起来直白新手入门时逻辑更清晰。后续如果追求并发性能可以换成异步 API那是进阶话题。headlessTrue表示无头模式也就是浏览器不显示窗口在后台跑。这是服务器部署的常态。但我要特别建议初期调试时把headlessFalse让浏览器窗口弹出来你可以亲眼看到页面加载过程。这种“看得见”的调试方式能极大帮助你建立对浏览器自动化操作的感觉。page.content()这个方法是关键中的关键它拿到的是当前 DOM 树渲染完成后的 HTML 字符串而不是网络请求的原始响应。也就是说前端动态创建的所有节点都在里面。这正是本次实战标题里“渲染后 HTML”的含义。你可以试着打开任意一个动态网站对比一下 requests 拿到的 HTML 和page.content()拿到的 HTML会发现差异非常大——后者多了成百上千个动态生成的节点。2.3 异步 API 的适用场景同步 API 足够覆盖绝大多数教学和中小规模采集场景但如果你要同时处理几十个页面同步方式就力不从心了。我这里简单提一下异步写法的样子import asyncio from playwright.async_api import async_playwright async def main(): async with async_playwright() as p: browser await p.chromium.launch() page await browser.new_page() await page.goto(https://example.com) html await page.content() await browser.close() asyncio.run(main())核心逻辑一样只是加上了await。异步的好处是并发能力强但调试难度也上了一个台阶。我的建议很务实先精通同步 API遇到性能瓶颈再迁移异步不要一上来就追求高并发那样很容易被各种异常搞崩心态。3. 渲染后 HTML 的精准获取与页面状态判断3.1 多种获取 HTML 的方式对比这次实战项目的第一个核心目标是“获取渲染后的 HTML”。我看到很多刚接触 Playwright 的人只会用page.content()但实际项目中根据场景不同获取 HTML 的方式有讲究。方式关键 API适用场景注意事项整页 HTMLpage.content()存档、全文解析拿到的是当前 DOM 序列化结果实时性最强元素级 HTMLpage.inner_html(selector)只关心某个容器内的结构避免了整页解析的庞大开销外部 HTMLpage.eval_on_selector(selector, el el.outerHTML)获取元素自身及其属性和 inner_html 的区别在于是不是包含元素自身标签响应体 HTML拦截响应获取特殊调试场景和渲染结果有差异注意区分举个例子假设目标有一个 id 为product-list的容器里面是异步加载的商品卡片。用整页 HTML 再筛也能出结果但最优雅的方式是page.goto(url) page.wait_for_selector(#product-list .product-item) html page.inner_html(#product-list)这样拿到的是纯商品列表的结构后续解析数据时噪音小得多。很多爬虫高手写动态页面的数据提取都倾向于先收窄范围再解析效率差距在数据量大的时候非常明显。3.2 判断渲染完成的正确姿势这是整个动态采集流程中经验含量最高的环节也是新手最容易踩坑的地方。用sleep固定等待几秒看起来简单但网络环境波动、页面逻辑复杂时固定等待要么不够导致元素没渲染出来要么浪费大量时间本来 1 秒就完成了硬等 5 秒。Playwright 提供的等待策略是我最推荐入手的# 等待某个元素出现 page.wait_for_selector(.product-item, timeout10000) # 等待某个元素消失适合加载动画场景 page.wait_for_selector(.loading, statedetached) # 等待网络空闲 page.wait_for_load_state(networkidle)这里有个非常重要的经验networkidle是双刃剑。它的定义是“网络连接数量降到 0 保持一段时间”听起来很理想但实际中有些页面会持续发送心跳请求、埋点请求导致这个状态永远不会达成最终白白耗尽超时时间。我在实际项目中遇到过很多次这种坑。更可靠的思路是优先等待页面关键元素出现其次配合选择器状态、请求响应事件等做多重确认。说得更直白一点与其纠结“页面是不是完全准备好了”不如直接问“我关心的那个数据/那个元素到底出来没有”。你等的应该是你要的数据而不是页面整体状态。这个思路和很多人写测试用例时的等待逻辑非常像。3.3 用 HTML 对比定位数据缺失问题我在实战中经常做这样一个操作先存一份浏览器里看到的“对的 HTML”再存一份代码抓下来的“出现问题的 HTML”用文本对比工具去 diff。这一招的实战价值极高。曾经遇到过一个诡异问题页面上明明能看到商品价格但抓下来的 HTML 里就是没有。单独看代码、看数据都找不出原因。后来把两份 HTML 一对比才发现价格区域的结构用了自定义元素加 shadow DOM 的隔离方式普通的选择器根本无法穿透到内部。这个发现直接改变了后续的定位策略。所以当你觉得“页面里应该有这个数据但抓不到”的时候不要猜去对比。把两份 HTML 存成文件用对比工具看看差异在哪差异本身就是问题所在。这个方法比盲目试各种选择器高效得多。4. 截图定位可视化排查问题的最佳路径4.1 截图功能全景全页、元素、局部一网打尽实战项目的第二个核心目标是“截图定位问题”。为什么截图这么重要因为爬虫代码出问题时错误信息只能告诉你“什么失败了”但往往不能告诉你“为什么失败”。而截图可以还原现场让你像看监控录像一样看到浏览器当时的状态。Playwright 的截图 API 很友好分为几档# 全页截图包括滚动区域之外的部分 await page.screenshot(pathfull.png, full_pageTrue) # 元素截图只截某个节点 element page.query_selector(.product-card) element.screenshot(pathelement.png) # 可视区域截图 await page.screenshot(pathviewport.png)full_pageTrue是杀手级功能。它会把整个页面滚动截取并拼接完整记录超长页面的所有内容。这个能力在记录“首屏看不到的问题”时很关键——比如某个元素在页面底部首屏截图根本看不到但全页截图能一览无余。4.2 截图定位的典型实战流程手把手教你排查我在带新人做动态采集时总结了一套截图排查的标准流程现在分享出来第一步在关键的步骤处埋点截图。不是整个流程只截一张图而是在“打开页面后”“滚动后”“点击后”“提取数据前”分别截图。这一步的目的是还原每一步操作后页面的真实状态。第二步对比“预期截图”和“实际截图”。你和预期可视化地比对很容易发现差异。有一种很典型的情况代码里等待了 3 秒但实际截图显示数据还没加载出来这就说明等待策略需要调整。第三步将截图和日志结合分析。截图显示的是结果日志记录的是过程两者结合定位效率翻倍。第四步定位到问题后回到对应的代码位置针对性地修复。我这里用一次真实排查来完整演示这个流程。当时目标是把一个滚动加载的列表全部抓完但运行结果发现只有第一屏的数据再往下就没有了。我一开始怀疑是滚动事件没触发于是写了page.mouse.wheel操作相关的调试代码。最直接的排查手段是截图先在滚动前截一张滚动后截一张。对比后发现页面确实滚动到了底部但仍然没有触发新的数据加载。这说明问题不在“有没有滚动”而在“滚动的方式”上——有些网站监听的是特定容器内滚动而不是页面级滚动。调整滚动目标后数据就能正常加载了。这个过程如果不看截图光靠猜不知道要折腾多久。4.3 截图保留现场异常处理的正确姿势好的异常处理不只是打印错误日志更是把现场证据完整保留下来。我推荐的姿势是在异常处理器里同时记录三样东西错误堆栈、当时的 HTML截取关键部分、屏幕截图。try: page.goto(url) page.wait_for_selector(.item, timeout5000) except Exception as e: page.screenshot(pathferror_{timestamp}.png) with open(fpage_{timestamp}.html, w, encodingutf-8) as f: f.write(page.content()) raise e这样做的价值在于你不用立刻去查出错原因先积累现场素材等有空再分析。尤其是批量跑任务时这种排查方式能省去大量重复调试时间。我做采集任务时这个套路基本上已经成为条件反射了。5. 常见问题与排查技巧实录5.1 超时问题与等待策略实例分享Playwright 最典型的报错就是超时错误。不同场景下的超时原因和解决思路差别很大这里整理成表供快速查阅报错特征常见原因解决思路导航超时goto阶段页面长时间不响应增加超时值或改用domcontentloaded状态等待元素超时选择器没匹配到元素或者元素渲染太慢检查选择器准确性、换更稳定的等待目标网络空闲超时networkidle被长连接请求拖住放弃networkidle改用等待目标元素文本断言超时页面存在但不是预期页面检查访问来源、登录态、页面跳转我最想强调的是遇到超时先别急着加大超时时间。加时间只治标不治本。正确顺序是先看截图确认当时页面是什么状态再查选择器是否有多个匹配或匹配了隐藏元素最后才考虑调整时间参数。还有一个很多人容易忽略的坑默认等待的元素可能在 DOM 里存在但是在屏幕外或者不可见的区域。Playwright 和 Selenium 一样交互类操作要求元素可见如果只是在 DOM 里但视觉上不显示相关操作会失败。这种问题靠截图一眼就能看出来。5.2 资源加载优化为什么你的脚本这么慢运行了一段时间 Playwright 后很多人会困惑明明页面很简单为什么执行速度这么慢原因通常是浏览器加载了大量用不上的资源图片、字体、广告脚本、埋点脚本等。优化思路是主动拦截这些无关请求async def route_handler(route): req route.request if req.resource_type in [image, font, media]: await route.abort() else: await route.continue_() page.route(**/*, route_handler)route拦截是 Playwright 的一个高性能特性。通过拦截图片、字体等资源实测下来一些页面的加载时间能缩短 30% 到 60%。还有更细致的玩法是把网络切换到 offline 模式来测试页面离线表现或者拦截某些特定的接口请求来修改响应这些在反爬对抗和调试场景中极其有用。不过要注意拦截资源是一把双刃剑。有些页面的核心逻辑会等待图片加载完成后才展示数据如果你把图片全拦了反而可能导致数据区域不渲染。所以我的建议是先小范围拦截截图看效果逐步调整拦截策略。5.3 反爬环境下的 5 个关键细节爬虫做到后面绕不开反爬的话题。Playwright 在反爬场景下的优势是真实的浏览器环境但也并不意味着万事大吉。我在实战中总结过 5 个关键细节第一User-Agent 设置。默认的 UA 虽然带浏览器标识但反爬系统还是可能识别出自动化特征。建议设置成真实浏览器的 UA而且要和你启动的浏览器内核版本匹配。context browser.new_context( user_agentMozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/120.0.0.0 Safari/537.36, viewport{width: 1920, height: 1080}, )第二Viewport 和时区等环境参数。一个默认的 headless 浏览器窗口尺寸可能和真实设备不一致反爬系统会检查这些细节点。建议按目标设备模拟。还有时区、语言、地理位置等参数都可配置。第三不要总是用无头模式。有些反爬极强的网站检测到navigator.webdriver为 true 就会拒绝。Playwright 可以启动有头模式配合虚拟显示。对于重要目标真实浏览器模式配合专业配置效果好得多。第四增加合理的人性化操作。连续请求速度极快、频繁用鼠标滚轮瞬间滚完一屏这类行为在服务端看来都比较可疑。适当地添加随机等待模拟真实用户节奏是必要的。第五代理 IP 的准备。这个需要特别强调我不展开任何具体工具或操作细节只说明原理——当目标网站对单 IP 的访问频率做限制时换 IP 是常规手段。对于新手更重要的事情是把页面逻辑搞清楚不要把精力都放在对抗上因为反爬是攻防竞态没有一劳永逸的解决方案。还需要特别提醒一个合规问题任何采集行为都必须在尊重目标站点服务条款的前提下进行控制合理频率不要对目标服务器造成压力。技术是工具怎么用要守规矩。5.4 其他值得收藏的实战技巧再补充几个我在实战中沉淀的小技巧都是踩过坑换来的关于选择器优先使用固定属性或语义化标签减少对层级路径的依赖。层级一变代码就得跟着改维护成本很高。关于浏览器复用同一个上下文对象可以打开多个页面让登录状态在多个任务之间共享。我的经验是登录流程一直很费时且容易被识别如果一套账号要抓多个页面尽量在同一个上下文中操作。关于反序列化状态的复用可以把登录后的存储状态保存到文件下次直接加载省掉重复登录。但要注意账号安全和会话时效的问题。关于页面对象过多导致的内存泄漏记得用完的上下文及时关闭。大规模任务建议限制并发页面数并在任务结束后显式释放资源。关于数据提取后的落地推荐把page.content()或inner_html的结果及时存储到本地文件或数据库中间层再离线解析。这样即使后续解析代码反复调试也不会反复请求目标站点减小服务器压力也加快自己调试速度。6. 最后的经验之谈这套渲染后 HTML 加上截图定位的玩法是我自己从无数个调试到深夜的案例里提炼出来的思维模式。核心不是某一个 API 用得有多溜而是建立一个“看证据”的习惯把浏览器里真实发生的状态存下来再和预期对比差异就是问题根源。HTML 是结构的证据截图是视觉的证据日志是过程的证据三个证据链合起来再玄学的问题都能找到解释。对于刚入门的朋友我强烈建议你踩着我的路线走先跑通最小脚本极力熟悉content()和screenshot()这两个 API然后用一个真实目标页面反复练习等待策略的调整。等你积累几十次失败和排查的经验动态页面在你的眼里就不再是难题反而变成一个好玩的挑战。最后再说一个小技巧调试时不要一上来就追求无头模式跑通全流程永远先在可视化模式下手把手地梳理一遍关键交互步骤确认每一步浏览器行为都符合预期再切到无头模式做批量运行。这个习惯能帮你省掉的 debug 时间不是一点点。
阅读完成 · 觉得有帮助？
