爬虫圈里有一个很常见的场景你用 requests 把页面抓下来高高兴兴准备解析结果发现 HTML 里空荡荡的数据根本不在里面只有一堆 script 标签和网页骨架。这时候你才意识到这个站点的内容是靠 JavaScript 动态渲染出来的。本小节是《Python 爬虫零基础入门》动态页面系列的第一课我们直接用 Playwright 来解决这个问题。目标非常明确打开一个动态页面等待需要的元素出现最后拿到渲染完成后的 HTML。我不打算讲那种读文档式的罗列而是把第一次上手 Playwright 时最该知道的事情讲透。包括为什么 requests 搞不定动态页面、Playwright 和 Selenium 比到底赢在哪、安装要注意什么、等待元素为什么会翻车以及拿到的 HTML 怎么验证是不是真的渲染完。这一节学完你能独立写一个最小可用的动态页面爬虫脚本后面再遇到滚动加载、点击翻页、iframe 这类进阶玩法都是在这个基础上加东西。1. 为什么静态请求抓不到动态内容1.1 请求库拿到的是源代码不是渲染结果很多人第一次接触爬虫时都以为网页就是一个 HTML 文件服务器返回什么浏览器显示什么requests 拿到的就是什么。这个认知在十年前大体上成立但现在越来越多的网站不是这么工作的。用 requests 请求一个页面拿到的其实只是服务器响应里那串原始字节。如果这个页面的内容是后端直接拼好的 HTML那没问题你拿到什么就能解析什么。但如果页面里只有一堆空壳标签真正的数据要通过 JavaScript 去某个接口取回再动态填充到页面上那 requests 就无能为力了。因为 requests 不会执行 JavaScript它只负责把服务器返回的原材料搬回来。我通常会给新手一个比喻requests 像你走进餐厅跟服务员说菜单给我看看你拿到的是菜单但后厨到底做了哪几道菜、菜长什么样、摆盘漂不漂亮你完全不知道。浏览器则是一个坐在餐桌前的顾客JavaScript 是后厨上菜的过程等菜全部端上来你看到的就是最终呈现的页面。动态页面爬虫解决的就是这个落差不满足于看菜单而是等菜上齐然后把整桌菜完整地拿回来。1.2 怎么快速判断一个页面是不是动态渲染在动手写代码之前有个更重要的问题你怎么知道当前要爬的页面是静态还是动态方法很简单用浏览器打开目标页面按 F12 打开开发者工具切到 Network 面板刷新页面找第一个文档请求通常是document类型。点开这个请求看 Response 选项卡里返回的 HTML。如果里面已经包含了你想要的数据那就是静态页面直接用 requests 就能搞定。如果返回的 HTML 里只有div idapp这种空壳而数据在你滚动页面后才出现或者要在 JS 执行完成后才填充那就是动态页面。还有一个更容易感知的特征你直接用浏览器查看网页源代码CtrlU和你按 F12 在 Elements 面板里看到的 HTML 不一样。Elements 面板展示的是 JavaScript 渲染后的 DOM而查看源代码展示的是服务器原始返回。两者不一致就说明有动态渲染。这种情况如果还想用 requests 硬抓要么你手动分析里面的 JS 接口要么上自动化浏览器工具。分析接口是一条路但很多时候接口有加密参数、有 sign 签名校验、有频繁更换的反爬策略费时费力。Playwright 这类工具的价值在于它直接绕过分析前端逻辑这层复杂度用真实浏览器把结果跑出来给你。2. 环境准备装库、装内核、跑通第一个脚本2.1 为什么选 Playwright 而不是 Selenium 或 Pyppeteer提到自动化浏览器老一代爬虫工程师第一反应多半是 Selenium。Selenium 确实能干活但它的问题是慢、配置繁琐还得额外装浏览器驱动版本不对就报错。Pyppeteer 是 Python 对 Puppeteer 的非官方移植能解决部分动态渲染问题但它的维护状态不太稳定API 也没有官方保证。Playwright 是微软开源的项目核心优势在于三点。第一安装简单一条 pip 命令装库再一条命令下载浏览器内核驱动不用你管。第二API 设计得很清爽等待机制是内置的很多 Selenium 里要手动写轮询的地方Playwright 一个wait_for_selector就解决了。第三它原生支持多浏览器和移动端模拟同一个 API 可以驱动 Chromium、Firefox、WebKit做爬虫时还能顺便模拟手机 UA绕过一部分只针对 PC 端的反爬限制。从我实际使用的体验看Playwright 最大的亮点是默认行为更聪明。比如页面跳转时它会自动等待主要加载事件完成你定位一个元素时它会自动等待元素出现。这些细节在 Selenium 里需要额外配置在 Playwright 里是默认行为。后面几节你自己写代码会发现大部分等待问题都已经被框架消化了。2.2 安装 Playwright 和下载 Chromium 内核先装 Python 库。建议用虚拟环境避免污染全局环境。命令行执行pip install playwright装完之后验证一下版本python -m playwright --version如果能看到类似1.4x.x的版本号说明库装好了。这时候还差最关键的一步——下载浏览器内核。Playwright 不像 Selenium 那样要求你手动找驱动它自己有一套浏览器内核管理机制你只需要执行python -m playwright install chromium这条命令会把 Chromium 内核下载到本地缓存目录。注意它下载的不是你电脑上装的 Chrome而是一个独立打包的 Chromium 浏览器版本。这样做的好处是内核版本固定不会因为系统浏览器升级导致行为不一致。坏处是下载体积比较大通常一两百兆耐心等一会儿就行。如果你在国内网络环境下载很慢可以设置 Playwright 的镜像源环境变量再执行 install这个细节网上有很多资料这里就不展开了。下载完成后建议跑下面这个最小脚本验证环境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()) print(page.url) browser.close()能打印出标题和 URL说明整个环境就通了。注意如果你在服务器或者无图形界面的环境下运行把headlessFalse改成headlessTrue。平时调试建议开有头模式亲眼看到浏览器在做什么排查问题时思路会清楚很多。2.3 搞清楚 Playwright 的架构不然后面容易迷路很多人第一次写完上面的代码虽然跑通了但对 Playwright 的组织方式还是很懵。这里用最简单的话梳理一下sync_playwright()是整个工具的入口它负责启动 Playwright 服务从这个入口里你可以launch()一个浏览器实例浏览器实例里面可以开多个page就是我们说的页面标签页每个page里你可以做导航、点击、输入等操作。这套层次结构跟真实浏览器是对应的一个浏览器进程里可以有多个标签页每个标签页是一个独立的page对象。做爬虫时你绝大多数时间都在操作page对象。记住这个关系后面章节里看到browser、context、page这三个词就不会再搞混了。context这个概念稍微复杂一点你可以先把它理解为一个独立的浏览器上下文相当于一个隐身标签页组不同的 context 之间 cookie 和本地存储是隔离的后面做多账号并发时很有用。3. 第一次打开页面核心三步流程3.1 先掌握同步 API再考虑异步Playwright 官方提供两套 API一套是sync_playwright同步写法一套是async_playwright异步写法。对于刚接触动态页面的爬虫新手我的建议是老老实实从同步 API 开始。原因是爬虫脚本的逻辑通常是线性的打开页面、等元素、取数据、写文件。用同步写法代码从上往下读每一步完成之后才执行下一步心智负担小。异步 API 需要写async/await虽然性能上更好但对还没理解事件循环的人来说坑太多。等你把同步 API 玩熟练了发现并发需求了再切换到异步版本也不迟。后面这个系列的所有代码我都会用同步 API 来写这样你跟着敲就能跑。3.2 最小可运行脚本逐行解析下面这段代码是我每次带新手入坑 Playwright 都会让他们先跑起来的版本。它的功能很简单打开一个动态页面打印标题和当前 URL然后关闭浏览器。from playwright.sync_api import sync_playwright # 用 with 语句管理 Playwright 生命周期 with sync_playwright() as p: # 启动 ChromiumheadlessTrue 代表无头模式不弹浏览器窗口 browser p.chromium.launch(headlessFalse) # 创建一个新的页面对象 page browser.new_page() # 打开目标网址 page.goto(https://example.com) # 获取并打印页面标题 title page.title() print(页面标题:, title) print(当前 URL:, page.url) # 关闭浏览器释放资源 browser.close()逐行来看。with sync_playwright() as p:这行很关键。Playwright 在进入with块时启动内部服务退出时自动清理避免你忘记关闭连接从而留下僵尸进程。你在所有 Playwright 脚本里都应该保留这个外层结构。p.chromium.launch(headlessFalse)是启动浏览器实例。headless参数决定了浏览器是否有窗口。调试阶段建议设成False这样你能看到浏览器真实操作过程定位问题时非常直观。browser.new_page()相当于新建一个标签页。在 Playwright 的世界里页面对象page是你所有的操作目标跳转、等待、点击、提取信息都是通过page来完成。page.goto(https://example.com)是让页面跳转到指定网址。这一步是阻塞的但怎么判断加载完成其实很有讲究。默认情况下它会等待页面的load事件触发也就是页面上主要的资源图片、样式、脚本加载完成。但这不等于你需要的动态内容一定加载出来了后面第 4 节会专门讲等待。page.title()返回当前页面的标题page.url返回当前页面最终的 URL。这里有个容易被忽略的点很多网站会做 302 跳转page.goto()之后浏览器地址栏里的 URL 往往不是原始输入的那个 URL。如果后续你需要拼接链接做翻页一定要用page.url来取值而不是自己死记初始地址。3.3 默认页面加载机制为什么有时候 goto 返回了你却不放心page.goto()默认的等待机制到底是什么经常看文档的人会发现goto()有个wait_until参数可以设置成load、domcontentloaded、networkidle、commit这几种状态。默认值是load意思是等待页面的window.onload事件触发。对大部分页面来说这意味着页面的静态资源已经加载完了。但这和我们要爬的动态内容完全是两回事。举一个真实的例子假设你需要抓一个股票行情页面它的 HTML 骨架在load事件触发时已经渲染好但具体的实时行情是 JS 在load后才向服务器发请求拿到的这时如果你立刻去提取数据大概率只能拿到空值。所以如果你第 3.2 节那个案例运行后发现浏览器能打开、但取不到想要的元素不要怀疑代码写错了问题几乎都出在不知道该等什么。这也是我强调要用page.wait_for_selector()而不是单纯依赖goto()的原因下一节专门讲。4. 等待元素出现用显式等待替代瞎等4.1 wait_for_selector 是入门必学在动态页面爬虫里等待是一门基本功。很多新手习惯一上来就time.sleep(5)等 5 秒再继续操作。这个方案不是不能用但毛病很大。网络环境好的时候等 5 秒是浪费网络环境差的时候等 5 秒可能不够。而且有的动态页面是异步分批加载的你睡够 5 秒也不一定数据完整。Playwright 提供了一种更优雅的方式显式等待等某个元素出现或满足条件再继续。最常用的方法就是page.wait_for_selector()。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) # 等待 id 为 content 的 div 元素出现最长等待 10 秒 content_div page.wait_for_selector(#content, timeout10000) print(元素出现了, content_div) browser.close()wait_for_selector()的逻辑是先立即查找有没有匹配 selector 的元素如果没有它就在内部不断的轮询 DOM直到元素出现或者超过timeout时间。返回的是一个ElementHandle对象你可以把它理解为一个指向真实 DOM 元素的句柄通过它可以进一步做文本提取、属性获取等操作。timeout参数单位是毫秒默认值是 30 秒。我建议在实际爬虫里不要用默认值而是根据页面复杂度显式设置比如 10 秒或 15 秒。设太短容易误判设太长遇到异常页面会干等很久。还有一个经验如果某个页面在正常情况下 5 秒内元素必现但你设了 10 秒仍然频繁超时那大概率不是等待时间问题而是页面本身出了问题比如被风控拦截跳到了验证码页或者接口炸了。这时候就该去检查当前页面真实内容而不是一味地加长超时。4.2 深入理解 WAIT_UNTIL 的五种状态goto()里wait_until参数一共有五个可选值写代码之前值得花几分钟把它们搞清楚。取值含义适用场景commit服务器响应头返回、连接建立页面开始加载极快的跳转基本不用在爬虫里domcontentloadedHTML 文档被完全加载和解析但样式、图片可能还没加载页面资源较多但动态数据不依赖图片时load页面所有资源含图片、脚本加载完成默认值常规页面首选networkidle网络请求基本空闲500ms 内没有新请求需要确保动态请求全部完成后取数据时visible等待元素从隐藏变为可见适用于弹窗、懒加载等场景我的个人经验是作为爬虫networkidle最稳但代价是慢。因为它要求 500ms 内没有任何网络请求而不少页面会持续轮询接口或者加载广告导致networkidle长时间不触发。所以反过来我通常不会在goto()里堵这个状态而是直接用一个常规的load后面跟一个wait_for_selector()去等真正关心的元素。这样效率和安全都兼顾。visible这个状态其实很有用。有些页面元素在 DOM 里已经存在但是它不可见比如下拉菜单未展开时。如果你只是要提取隐藏数据presence状态就够了但如果你要模拟用户点击某个按钮那必须确保元素是visible的。Playwright 的wait_for_selector()默认等的是元素存在presence如果要等它可交互可以加上statevisible参数。另外Playwright 还提供了page.wait_for_load_state()方法可以单独等待加载状态。这在点击按钮触发新页面跳转时特别有用。比如你点击了下一页如果直接抓数据可能页面还没切过去先wait_for_load_state(networkidle)就能大大降低出错概率。初次学习不用掌握所有细节把wait_for_selector和wait_for_load_state两个方法用熟就够了。4.3 兜底等待方案与调试技巧虽然有显式等待但实际开发中有些场景还是比较麻烦。比如页面加载完成后某项数据是异步接口慢慢吐出来的接口又没办法直接探测。这时候我有两个兜底习惯。第一个是page.wait_for_timeout()它本质上还是sleep但比time.sleep()好在不需要手动导入time模块而且在异步环境下也安全。我通常用它来做二次确认比如等待 500ms 让动画过渡完成而不是把整个等待逻辑压在它身上。第二个是自定义轮询循环。你可以这样写import time for i in range(10): count page.locator(css#comment-list .comment-item).count() if count 20: print(评论区加载完成共, count, 条) break time.sleep(1)这种方式的好处是灵活你可以按照业务条件来判断到底等到了没而不是单纯等元素存在。比如评论区的数据是分页加载的第一屏只有 10 条要等到第 20 条出现才说明数据已经积累了足够样本。这种情况下wait_for_selector只能告诉你DOM 里有这个元素却判断不了数量而轮询循环可以。调试时还有一个小技巧我几乎每次写动态页面爬虫都会用在等待目标元素之前先把当前页面的内容打印出来看看。page.wait_for_timeout(2000) print(page.content()[:1000])如果打印出来的内容和你预期不符不用怀疑肯定是等待条件选错了或者页面本身没进到你想要的地址。先看页面长什么样子再决定下一步怎么改这是排查问题最高效的路径比对着代码瞎猜靠谱得多。5. 拿到渲染后的 HTML并解决提取的还是空壳的问题5.1 三种吐出 HTML 的方式对比现在到了本小节的高潮部分——拿渲染后的 HTML。Playwright 提供了好几种方式我按使用频率给你排个序。第一种是page.content()它返回的是当前页面完整的 HTML 字符串也就是浏览器开发者工具里 Elements 面板看到的那份。这个适合你需要保存整个页面快照或者把整段 HTML 丢给 BeautifulSoup 做解析的情况。html page.content() with open(page.html, w, encodingutf-8) as f: f.write(html)第二种是page.inner_html(selector)它返回指定元素内部的 HTML 内容。如果你已经通过wait_for_selector()找到了目标区域比如某个div#content那么inner_html可以直接把这个区域里的结构拿出来省去你再去全文里切片。page.wait_for_selector(#content) inner page.inner_html(#content)第三种是locator.inner_html()用定位器的方式来取。这里稍微解释一下locator和wait_for_selector返回的ElementHandle的区别locator是更现代的定位方式它不止能定位还能执行count()、click()、inner_text()等操作。建议在比较复杂的页面里统一用locator而不是wait_for_selector。content_locator page.locator(#content) print(content_locator.inner_html())还有几个相近的方法比如inner_text()是去掉 HTML 标签后的纯文本text_content()是更底层的文本获取get_attribute()是拿属性值。爬虫取标题、价格这类简单文本时我通常用inner_text()需要保留链接、图片结构时用inner_html()要拿a标签的href时用get_attribute(href)。5.2 一个完整流程示例加载、等待、断言、保存我给你写一个完整的、真正可以改改就跑的例子。假设我们要爬一个用 JS 渲染的博客列表页列表项都在div.post-list下的.post-item里每个.post-item有一个标题。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/posts, wait_untilload) # 等待文章列表容器出现 page.wait_for_selector(.post-list, timeout15000) # 等待列表里的第一篇文章出现确保动态数据已填充 page.wait_for_selector(.post-item, timeout15000) # 提取标题 titles page.locator(.post-item h2).all_inner_texts() print(抓取到标题数量:, len(titles)) for t in titles[:5]: print(t) # 保存整个渲染后的 HTML html page.content() with open(posts_page.html, w, encodingutf-8) as f: f.write(html) browser.close()看到几个关键动作了吗我先等容器再等列表项因为容器只是空壳列表项才是数据填充后的结果。all_inner_texts()是批量获取所有匹配元素的文本返回一个列表。如果你只需要第一个标题可以换成first.inner_text()。page.content()拿到的 HTML 是整个页面渲染完成后的 DOM。不过要注意page.content()在页面有大量动态资源时拿到的 HTML 可能包含一堆额外生成的脚本标签和属性文件会很大。如果你只关心某个区域用page.locator(.post-list).inner_html()会干净很多。5.3 怎么验证这确实是渲染完成后的数据这个问题很多新手不会问但实际工作中特别关键。你拿到 HTML 后怎么确认它是渲染完成而不是渲染到一半的最直接的办法是断言。你可以wait_for_selector一个代表数据已就绪的元素比如分页按钮、加载完成提示、某个特定数量的列表项。如果这个元素出现说明页面的核心数据已经到位此时再取 HTML可靠性会大幅领先于盲目sleep。第二种验证方式是检查关键文本是否在页面里。比如html page.content() assert 发布时间 in html, 页面还没有加载出发布时间字段这种断言逻辑适合作为爬虫脚本的自动防呆。如果页面结构变了或者被反爬拦截了脚本会立刻报错而不会带着错误数据往下跑。第三种方式是把 HTML 存下来之后用 BeautifulSoup 重新解析一遍。这一步实际上是在做二次校验。我习惯把 Playwright 当作获取渲染后原始 HTML 的工具拿到之后用parsel或BeautifulSoup继续解析因为它们在处理复杂选择器、做列表循环时比在浏览器上下文里操作更顺手代码也更清晰。但这里要注意一个容易犯的错你用page.content()拿到的 HTML和用page.locator().inner_html()拿到的局部 HTML编码和动态生成的部分可能有微小差异。在做字符串匹配时最好先把 HTML 统一按utf-8保存再用BeautifulSoup(html, html.parser)解析避免中文乱码问题。6. 常见问题排查与实操经验6.1 常见问题速查表我把第一次跑 Playwright 时最常遇到的几个问题整理成了一张表方便你对照排查。问题原因解决方案代码报错Executable doesnt exist没下载 Chromium 内核或者内核路径不正确执行python -m playwright install chromium页面打开后get不到任何元素使用了goto()后立即解析没等动态数据渲染用wait_for_selector()等待目标元素出现wait_for_selector一直超时选择器写错了或者页面被重定向到验证码页先打印page.content()看当前页面实际内容拿到 HTML 全是脚本标签没有业务数据页面内容经过加密渲染或数据在 iframe 里检查 iframe 元素后续章节会讲 iframe 处理浏览器窗口闪一下就退出没有用wait_for_timeout或 input() 暂停脚本执行完就关闭在browser.close()前加page.wait_for_timeout(3000)观察状态CDP 连接断开或浏览器崩溃内存不足或启动参数有问题减少并发页面数量合理设置headless中文打印乱码控制台编码问题或 HTML 编码识别错误在代码里加sys.stdout.reconfigure(encodingutf-8)保存文件时指定encodingutf-8这里面我要多说一句如果wait_for_selector超时第一件事真的不是加长 timeout而是去看当前页面到底是不是你想要的页面。有时候是登录过期跳转到了登录页有时候是反爬跳到了验证码页有时候是目标站点临时改版把元素类名改了。我见过太多人对着一个#content的 selector 反复调 10 秒、20 秒、60 秒最后发现页面根本没加载出来。先把page.content()打印出来看一眼比什么都好用。6.2 容易被忽略的四个实操细节第一个细节是用户代理User-Agent。Playwright 启动的 Chromium 默认 UA 里会带HeadlessChrome字样如果目标网站对无头浏览器做了识别很容易被拦截。一个稳妥的做法是启动时设置一个常规浏览器的 UAbrowser 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/120.0.0.0 Safari/537.36 ) page context.new_page()这里你可能会注意到我没有直接用browser.new_page()而是先创建context再new_page()。这是因为很多反爬参数UA、viewport、语言都是挂在context这一层上的。后面如果要做更精细的指纹伪装也都围绕context来做。第二个细节是视口大小。很多前端框架会根据屏幕宽度渲染不同的布局比如 PC 端显示列表移动端显示卡片。如果你用默认视口1280x720 之类的有时反而触发精简模式。我一般会根据目标站点的设计习惯设置一个匹配的 viewportcontext browser.new_context( viewport{width: 1920, height: 1080}, localezh-CN )第三个细节是资源加载优化。动态页面往往有很多图片、广告、统计脚本它们对数据提取毫无帮助但会拖慢加载速度。你可以用page.route()拦截掉这些资源import re def block_unneeded(route): if route.request.resource_type image: route.abort() else: route.continue_() page.route(re.compile(r\.(png|jpg|jpeg|gif|webp)$), block_unneeded)这样做的好处是页面加载速度能快好几倍而且不容易触发图片类的流量告警。但注意如果你需要爬取图片 URL 或者图片本身就不要拦截图片资源了否则会把你需要的文件全挡掉。第四个细节是合理管理浏览器生命周期。爬虫脚本如果长时间挂机运行Playwright 的浏览器进程可能积累大量内存。我的做法是定期重启浏览器实例比如每爬完 500 个页面就把浏览器close()再重新launch()。虽然启动浏览器需要几秒但比内存暴涨导致崩溃强得多。6.3 和现有爬虫代码整合的两点经验最后聊两句关键心得。第一个经验是Playwright 不必包办所有事。很多人学会 Playwright 后就恨不得所有页面都用它来爬其实这是多余的。对于静态页面requests 是更快、更稳、更省资源的选择。我自己的项目里通常是这样分工的先用 requests 和简单的选择器判断页面是不是静态的如果发现是动态页面才换 Playwright 上场。Playwright 用来抓取那些只能用它才能拿到的动态数据拿到 HTML 或者解析完数据之后还是照常用 pandas 存 Excel、用 SQLAlchemy 入数据库。不要把整个爬虫流程全部泡在浏览器里那样不仅慢而且维护成本高。第二个经验是关于定位元素的耐心。初次上手 Playwright 时你最不耐烦的一件事可能是明明我在浏览器里看到了这个元素为什么locator就是找不到这时候先别急着怀疑 Playwright而是打开开发者工具确认这个元素是不是在 iframe 里面或者是不是在 Shadow DOM 里面。iframe 里的东西要用frame_locator()来定位Shadow DOM 的元素获取方式也完全不同。这些属于动态页面进阶内容后面章节会单独讲。但你要记住这个排查顺序优先怀疑选择器写错然后怀疑页面加载未完成最后怀疑元素在特殊容器里。这三个因素覆盖了 95% 的找不到元素问题。再补充一个小习惯。每次写 Playwright 脚本我都会把目标页面中用于判断数据是否加载完成的 selector 单独抽成一个变量放在脚本顶部。这样页面改版时只需要改一处不用在几十行代码里翻来找去。这种对选择器的集中管理在维护长期运行的爬虫项目时价值极大。
