企业官网建设流程全解析

不知道你是不是也经常遇到这种尴尬：接手浏览器自动化的任务，第一反应还是开 Selenium，结果又得去找对应版本的驱动，浏览器一更新脚本就崩，等待全靠 sleep，写出来的东西同事们根本不敢维护。我最近大半年做自动化时，尤其是需要驱动微软 Edge 浏览器的场景，已经彻底转向了 Playwright + Python 这套组合。它解决的核心痛点很直接：跨浏览器统一、自带等待机制、录制脚本方便，而且对 Edge 的支持几乎可以说是“天生”的。

这篇教程（一）我会把从环境安装到浏览器启动、页面跳转、元素操作、截图调试的完整路径走一遍，内容适合刚接触 Playwright 的 QA 工程师、做爬虫和 RPA 的朋友，也适合那些被 Selenium 折磨到想换方案的老手。这一篇先把地基打好，后面再聊登录态保持、请求拦截、多页面并发这些进阶玩法。

1. Playwright + Python 驱动微软 Edge，到底赢在哪

1.1 这套组合解决了什么问题

先说个最简单的痛点。以前用 Selenium 驱动 Edge，你要先去下载跟浏览器版本完全匹配的 msedgedriver，浏览器一升级，驱动就对不上，启动直接报错。Playwright 对这个问题的处理方式是把浏览器内核下载管理做得非常统一，你安装好 Python 包之后，一条命令就能把 Edge 的驱动和可执行文件链路全部准备好，启动时直接指定 channel 为"msedge"就行。

另一个是“自动等待”。Selenium 里最痛苦的就是元素还没渲染出来，脚本就冲上去点击，然后报 NoSuchElement。Playwright 内置了 Actionability 检查机制，点击、填充、勾选这些操作都会自动等待元素可见、可点、可交互，不需要你到处塞time.sleep()，更不需要自己写WebDriverWait。我自己实测下来，脚本稳定性提升非常明显，之前一跑就挂的用例，换成 Playwright 之后基本能连续跑几个晚上不崩。

还有个容易被忽略的点：Playwright 的浏览器上下文隔离设计太适合做自动化了。每开一个新的 Context 就相当于一个干净的浏览器会话，cookie、缓存、localStorage 都是独立的。你可以在一个脚本里同时开登录态和未登录态两个上下文，互不干扰。这在处理“同一功能在不同登录状态下的表现”这类测试场景时，简直不要太顺手。

1.2 和 Selenium、pyppeteer 这些老方案相比差在哪

我做这个对比不是想拉踩，只是想把选型时的考量讲清楚。Selenium 的优势是生态成熟、会的人多，但它这几年的问题也在那摆着：维护成本高、驱动跟版本强绑定、等待机制弱、多标签页处理繁琐。

pyppeteer 是早期把 Puppeteer 搬到 Python 社区的项目，解决了一部分问题，但维护频率跟不上，而且默认操作的是 Chromium，想驱动 Edge 还得自己折腾路径。Playwright 是微软自己维护的工具链，对 Edge 的支持自然比第三方方案更稳。它的 API 设计也比 pyppeteer 更贴近日常业务逻辑，比如分角色定位get_by_role、直接拿到文本内容的get_by_text，读起来就像在写业务描述，而不是在写选择器魔法。

另外 Playwright 支持同步和异步两套 API，同一个定位器语法两边通用。你要是写并发任务，用异步风格干净利落；写普通脚本，用同步风格可读性高。Selenium 虽然也有异步方案，但实际用起来还是 Playwright 更顺。

从调试体验来说，Playwright 有个录制功能，playwright codegen会在你点击页面的时候自动生成代码。这个功能不是花架子，我第一次用的时候，十分钟就把一个之前要手动写半小时的流程给录完了，生成的代码虽然有时候选择器会偏长，但作为初稿去改，效率是真高。

1.3 这些场景最适合用这套方案

我个人觉得下面几类需求最适合直接上 Playwright 驱动 Edge：

• 自动化回归测试：需要稳定驱动浏览器跑多轮用例，对失败用例能快速截图和录视频。
• 数据采集与页面监控：需要打开指定网页，筛选信息、翻页、保存结果。Edge 的兼容性在 Windows 环境下表现好，很多内网页面也优先兼容它。
• RPA 流程替代人工操作：需要自动登录、填表、点按钮。此时 Edge 的用户数据目录还可以复用已登录的会话，省去重登流程。
• 需要同时跑多个独立会话的任务：比如对同一个系统做不同账号的并发验证，利用多 Context 隔离就不会串数据。

你要只是想快速打开个网页截个图，用别的脚本也能做，但一旦需求变得复杂，比如涉及用户状态切换、下载处理、多页面协作，Playwright 的价值就完全体现出来了。

2. 环境准备：把第一公里铺平

2.1 Python 环境与虚拟环境准备

先说 Python 版本，Playwright 官方要求 Python 3.9 以上，我这边环境用的比较多的是 3.10 和 3.11 版本，运行稳定。如果是老项目里还留着 3.8，我建议先升级环境，不然有些新特性不支持，后面跑起来一堆怪问题。

我强烈建议你在虚拟环境里装，不管你是用venv还是conda或者pipenv。原因不复杂：Playwright 依赖的包不少，如果不隔离环境，很容易和项目里既有依赖产生版本冲突。我之前在一个老爬虫项目里直接把 playwright 装进全局环境，结果把另一个库的依赖给顶掉了，排查了半天才意识到确实应该在环境里隔离。

创建虚拟环境这种基础操作我就简单给了，Windows 下我用的是：

python -m venv venv venv\Scripts\activate

Linux 或 macOS 下就是你熟悉的source venv/bin/activate。激活之后记得看一下python --version，确认没指错解释器。

2.2 安装 Playwright 包与 Edge 浏览器支持

虚拟环境激活后，安装包：

pip install playwright

这一步把 Python 库装好了，但还不够。Playwright 本质上是把你指定的浏览器内核下载到本地固定目录，然后通过它自己的驱动协议去控制。所以要继续执行：

playwright install msedge

这条命令会去拉取微软 Edge 浏览器的对应版本。注意，不是说你 Windows 机器上装了 Edge 就万事大吉了，Playwright 仍然需要自己的浏览器副本，这样版本内核才是可控的。如果你机器上根本没装 Edge，这条命令就帮你把 Edge 完整下下来，这是开箱即用的好处。

另外如果你只需要 Edge，就不要顺手执行playwright install不带参数，那个会把 Chromium、Firefox、WebKit 全部拉下来，体积很大。我一开始图省事执行了全量安装，结果磁盘里多出来好几 GB 浏览器的副本，其实很多根本没用到。用哪个装哪个就行。

如果你在服务器上跑无头模式，可能还需要装一些系统级依赖库，官方给了一条命令：

playwright install-deps

这个在干净的 Linux 容器上比较有用，它会根据你安装的浏览器把缺失的系统库补上，省得启动时因为缺 so 文件而报错。

2.3 用最小脚本验证链路是否打通

装完之后，建议你先把最小脚本跑通，再往里面加业务逻辑。我每次在新环境搭 Playwright，第一件事永远是开一个 Edge 实例，访问一个最简单的页面，打印标题，关闭。比如这样：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(channel="msedge", headless=False) page = browser.new_page() page.goto("https://example.com") print(page.title()) browser.close()

里面有个重点：p.chromium.launch(channel="msedge")这一句。这里别被chromium吓到，它其实是 Playwright 内部分类的方式，即便是驱动 Edge，也是走 Chromium 这个协议族的。你只要把channel参数显式指定为"msedge"，它就会启动微软 Edge 而不是原生 Chromium。

headless=False表示有头模式，你执行这个脚本时能直接看到 Edge 窗口弹出并打开页面。如果你是第一次跑，建议先不要用无头模式，因为你看得见运行过程中发生了什么，出了问题也更容易判断是哪一步没走通。

运行脚本后，如果控制台输出 example 域名的页面标题，说明整条链路已经通了。此时你的 Playwright 环境就算真正准备好了。

3. 核心实操：让 Edge 按你的脚本“动起来”

3.1 启动 Edge 的两种姿势：同步 API 与异步 API

Playwright 给了两套使用方式。同步 API 用sync_playwright()，里面写起来就像普通 Python 代码，适合大多数常规脚本。刚才的最小脚本就是同步版本，它的优势是思路直观，不需要考虑事件循环。

异步 API 用async_playwright()，配合await语法写，适合并发量较高的场景。举个例子：

from playwright.async_api import async_playwright import asyncio async def main(): async with async_playwright() as p: browser = await p.chromium.launch(channel="msedge", headless=True) page = await browser.new_page() await page.goto("https://example.com") print(await page.title()) await browser.close() asyncio.run(main())

如果你刚开始学习，我建议先用同步 API 把业务逻辑跑通，因为后续文章里讲解定位器、等待机制、上下文管理时，用同步模式更直观。等你有并发需求了，比如一次开五个页面分别做下载任务，再迁到异步模式。两套 API 在方法名上几乎一一对应，迁移成本不高。

还有一个细节值得提：browser.new_page()创建的是一个页面对象，而它天然绑定在一个默认上下文里。如果你想用独立的干净环境，建议先browser.new_context()，再通过context.new_page()创建页面。后面讲多账号隔离时，你会更能理解这个层次关系。

3.2 页面导航与加载等待：别再傻傻 sleep 了

导航的常用方法就是goto()，用法很简单：

page.goto("https://example.com", timeout=30000)

这里深入说的其实是“等待”。goto()默认会等待到页面load事件触发，也就是页面主要资源加载完毕。但实际开发里你会发现，很多页面load事件触发后，JavaScript 异步请求的数据还没回来，按钮可能还没渲染出来。这时候你如果立刻操作，Playwright 自己的 Actionability 机制会兜底：它会在定位到元素后进行可见性和可操作性检查，不行就继续等待。

但是有个经典误区：如果元素压根还不存在于 DOM 里，定位器默认会等一个超时时间，默认是 30 秒。有些脚本看起来像卡死了，其实就是在等待一个可能永远不会出现的元素。所以除了goto的等待，还要学会显式等待关键元素的出现：

page.wait_for_selector("text=登录", timeout=10000)

或者等待某个请求完成：

page.wait_for_response(url="**/api/user/info")

办这些等待逻辑时，我的经验是：可以自定义timeout，但不建议把这个值设得非常大，那只是掩盖问题。你要做的是把等什么应该发生想清楚，是等按钮出现，还是等数据请求返回，写清楚对应的等待条件才可控。

3.3 元素定位与常用操作：用接近业务语义的方式找元素

Playwright 的定位器体系比 Selenium 友好太多。最核心的套路是先用page.locator()或各种get_by_*拿到元素，然后再做点击、填写、勾选等动作。

常用的有：

# 按文本定位，非常适合按钮和链接 page.get_by_text("提交").click() # 按角色定位，比如 button、link、checkbox page.get_by_role("button", name="保存").click() # 通过 CSS 或 XPath 定位 page.locator("#username").fill("test_user") page.locator("xpath=//input[@name='password']").fill("123456")

这里有个很容易踩的坑：locator()默认接收 CSS 选择器，如果你直接写//div[...]这种 XPath 字符串，会报错。要么写成xpath=//div[...]，要么用page.locator("xpath=...")这种带前缀的形式。我一直觉得这个设计有意在逼你用更语义化的方式去定位元素，不至于满屏都是天书 XPath。

fill()是输入框专用，会自动聚焦再输入。如果你需要一个个按键触发事件（比如模拟搜索框自动补全的逐字输入），就要用press_sequentially()：

page.locator("#search").press_sequentially("python")

这个区别经常会遇到：fill()一次性设置值不会触发 keydown/keyup 事件，而press_sequentially()模拟真实按键，交互类页面会有不同的表现。在选择用哪个之前，想清楚你的页面到底监听的是 change 事件还是 keyup 事件。

3.4 窗口、标签页与多上下文管理

浏览器自动化的过程中，多标签页处理是另一个高频需求。页面里点击一个链接，新标签页打开了，如果你继续用原来的page对象去操作，就会找不到那个新页面。正确做法是用context层面来管理：

with context.expect_page() as new_page_info: page.click("a[target='_blank']") new_page = new_page_info.value new_page.wait_for_load_state("domcontentloaded")

这里的关键点是expect_page()必须先注册，再去触发打开新页的操作，否则事件错过之后你是拿不到那个新页面的。这个和 Selenium 里逐个遍历window_handles的思路完全不同，Playwright 的方式更贴近真实事件流。

多上下文我前面提到了，再展开一下。一个browser可以创建多个context，每个 context 有独立的 cookie、storage、UA 等。比如我有一个场景是要同时管理三个账号的状态，那我就会创建三个 context，每个 context 里再开一个页面，互不干扰。如果要模拟不同的设备，还可以在创建 context 时传设备描述符：

context = browser.new_context( viewport={"width": 393, "height": 852}, user_agent="Mozilla/5.0 (iPhone; CPU iPhone OS 17_0 like Mac OS X) ..." )

这样脚本跑出来的页面环境就是移动端效果，对响应式页面调试特别有用。

3.5 截图与基础调试：留证据也得有方法

截图是自动化刚需，尤其跑回归用例时，失败了最好直接留一张现场图。Playwright 截图非常简单：

page.screenshot(path="fullpage.png", full_page=True)

full_page=True截的是整个长页面，不是只有视口那一屏。这个参数很好用，但我建议截图之前想清楚路径，最好把每次运行的截图放到带时间戳的目录里，不然几千张图全叫fullpage.png，后面复盘根本分不清。

除了截图，Playwright 还支持录视频和生成页面 PDF（仅无头模式）。录视频的方式是在创建 context 传入record_video_dir：

context = browser.new_context(record_video_dir="videos")

跑完脚本以后你会得到每个页面的 webm 视频文件。排查那种“点击后页面没有任何反应”的疑难杂症时，视频比截图管用多了，因为你能看到鼠标悬停变化、等待过程、页面闪跳这些细节。

如果用playwright codegen录制，界面右下角会实时显示每一步对应的定位器代码，你可以复制出来改。我这里强烈建议你用录制代码做初稿，而不是做终稿，因为生成的代码常常会有多余步骤，且选择器不一定最稳定，最好人工优化一遍。

4. 实战中躲不开的坑与排查技巧

4.1 启动直接报错：驱动到底装哪了？

最常见的报错是类似Executable doesn't exist at ...，这一般就是playwright install msedge这一步没走，或者走了但安装目录被系统清理了。解决办法是重新执行安装命令，并确认输出里确实出现 completed 或者 installed 字样。

另一个报错情况是channel msedge not found，这通常发生在 Linux 服务器上，机器本身没有 Edge，安装命令又没执行成功。如果你确实需要 Edge 而不是 Chromium，就先检查网络能不能访问到下载源。很多公司的内网环境会拦 Playwright 的下载域名，这种情况下你要么走代理，要么离线安装包手动放置，但离线安装较为繁琐，我建议先确认网络策略再动手。

还有个小概率问题：Windows 上如果默认 Edge 版本特别老，而 Playwright 需要的内核版本较新，也会启动失败。此时别自己去下载 RGB 或 Beta 版，老老实实把系统 Edge 更新到稳定版或者让 Playwright 重新拉取它自带的副本更稳妥。

4.2 无头模式跑不动，时间到底怎么控制？

无头模式省资源，但有个特点：页面渲染和资源加载节奏跟有头模式不一样。很多时候脚本在有头模式好好的，一切成headless=True就报元素找不到或者超时。原因之一是页面在有头模式里会额外处理一些可见性逻辑，而无头模式下某些异步渲染时机不同。

解决思路不是调大 timeout 完事，而是把等待逻辑改显式一些。优先用expect_navigation()或者wait_for_selector()等关键节点，而不是一上来就点按钮。我在一个爬虫项目里遇到过：无头模式下页面数据要等两个接口都返回才渲染表格，我开始只知道等 load 事件，结果拿到的是空表格。后来改成等待表格内出现第一行数据才继续，问题就消失了。

顺便提一句批量任务跑无头模式时，建议把每个任务的日志打全，至少记录当前 URL、操作页码和耗时，不然出问题没法定位是第几步慢的。

4.3 元素定位不到，八成是你在等错误的东西

Playwright 报Timeout 30000ms exceeded并不是“元素不存在”，而是“在给定时间内没达到可操作状态”。所以排查第一件事不是加长超时，而是确认选择器是不是真的指向了唯一且正确的元素。

我遇到过两次比较典型的教训：一次是页面里有多个元素都匹配同一个 CSS 类，第一次点击操作没问题，第二次从列表里点第二项时，Playwright 因为定位到多个匹配项直接抛严格模式校验失败。这个设计其实是在保护你，它要求你用更精确的定位条件，比如加first、nth(1)或者带上文本过滤。另一次是按钮被遮罩层挡住，Playwright 会一直等它“可点击”，但遮罩永不消失。此时我一般会在调试模式下手动执行page.locator(...).hover()看元素位置，或者干脆在定位器里加click(timeout=5000)快速暴露问题。

真正好用的调试手段是locator.wait_for(state="visible")加局部超时，配合分步打印日志，几分钟就能定位是哪一层没出来。另外，浏览器控制台里如果能复制出准确的 XPath，就优先用它，CSS 选择器在现代前端框架里太容易因为动态类名失效了。

4.4 iframe 里的内容，默认就是抓不到

这个坑特别隐蔽。页面主体明明能看到 iframe 里面的输入框，但你用page.locator直接定位，就是找不到，报超时。原因是 iframe 属于独立的 DOM 树，你必须先指定进入 frame 才能操作里面的元素。

Playwright 提供了frame_locator来解决：

frame = page.frame_locator("iframe[src='login.html']") frame.locator("input[name='user']").fill("hello")

需要注意frame_locator返回的不是一个 Frame 对象，它只是把它内部的选择器解析逻辑限定到了对应 iframe 里。如果你的 iframe 是多层的，那么 frame_locator 可以链式调用：

frame = page.frame_locator("outer").frame_locator("inner")

在实际开发里，我建议一开始就要明确“我要操作的元素在哪个 frame 里”。判断方法很简单，在浏览器开发者工具的 Elements 面板里看它在不在<iframe>节点下。如果在，就别浪费时间在 page 层面找，直接用 frame_locator 落实到子框架。

4.5 文件下载被拦，配置一下就能解决

下载文件也是常见需求，这里同样要用事件监听方式。下载动作往往是点击一个触发按钮，但文件会异步输出，这就要用到expect_download：

with page.expect_download() as download_info: page.get_by_text("导出报表").click() download = download_info.value download.save_as("./reports/data.xlsx")

这里面要注意的点有三个。第一：save_as方法在较新版本里推荐优先使用，它通常是流式写入，优于直接读取download.path()再复制文件。第二：下载文件名有时是服务端通过 Content-Disposition 指定的，而download.filename就是最终名字，你可以拿它来校验是否下载正确。第三：如果下载启动了但expect_download超时了，优先检查是不是服务端返回了错误状态或者接口需要额外的认证头。你可以开启流量日志page.on("request", lambda req: print(req.url))来直观看到点击之后到底触发了哪些请求，这比无脑重试高效得多。

另外，如果你在做批量下载，尽量复用同一个 context，并且把下载目录固定下来，这样后处理代码能统一读取。还要提醒一点：无头模式下某些浏览器的下载安全提示行为与有头模式不同，如果发现下载莫名其妙失败，可以先切到有头模式复现一次，往往光这一步就能看出问题到底出在服务端还是浏览器端。

一点点个人体会

这套环境我前后搭过不少回，现在再拉起一个新项目，从安装到跑通第一个用例基本半小时内能搞定。最让我省心的还是“一个命令驱动 Edge”的设计，之前 Selenium 里维护驱动版本的那点麻烦，在 Playwright 这里被直接省掉了。如果你正从老方案迁移过来，这篇内容够你建一个好头；但真正的踩坑往往藏在后面的复杂场景里，比如登录状态怎么保存、请求怎么拦截修改、多任务并发怎么稳定跑完，这些我准备在系列的下一篇里逐个拆开讲。你先照着把环境跑通，然后动手写一个属于你自己的最小脚本，遇到问题欢迎按上面几个排查思路来对照。