企业官网建设流程全解析

1. 先搞清楚 Playwright 里的“页面”到底是什么

用 Python 写 Playwright 的人，十有八九会在多标签页、多窗口的场景里卡一下。原因倒不难理解：大家以前写 Selenium 写习惯了，脑子里默认是“一个 driver 对象对应一个浏览器窗口”，切换页面无非就是driver.switch_to.window(handle)，换个句柄的事。但 Playwright 的模型完全不是这个思路，它把浏览器抽象成了Browser → Context → Page三层结构，页面切换的本质是“持有不同 Page 对象的引用，然后决定先操作哪一个”。

这里的Page对象可以理解为浏览器里的一个标签页，它本身就是一个独立的运行时环境，有自己独立的 DOM、JavaScript 执行栈、网络请求队列。你注意一个关键点：在 Playwright 里，切换页面不是通过“激活某个窗口句柄”来实现的，而是把你手里的代码引用指向正确的 Page 对象。换句话说，你用哪个 Page 对象去调用page.click()，操作就发生在哪个标签页上。这个思维转换至关重要，搞懂它，后面所有花里胡哨的页面定位方法都只是 API 细节而已。

那什么时候会凭空多出一个新 Page？最常见的就是点击<a target="_blank">链接、执行window.open()、第三方登录的 OAuth 跳转、后台 JS 动态创建的新窗口。还有一部分人会把文件下载、iframe 弹窗也归到“多页面”里，这就不太准确了——下载走的是page.expect_download()，iframe 走的是frame_locator()，它们跟真正的新标签页不是一回事。这篇文章讨论的就是前者：多个独立标签页之间的切换与定位。

顺便说一句，很多初学者会把“定位页面”和“定位元素”混在一起问。其实它们各有各的套路：定位页面是找 Page 对象，定位元素是在当前 Page 里用locator()找 DOM 节点。两者的技术栈完全不同，网上教程容易把它们揉成一团，导致你搜半天也没搞明白自己卡在哪一步。我这篇的核心是“定位页面”，但也会在最常见的坑里顺带提一嘴两者交互时的注意点。

2. 多个页面的定位方案拆解

2.1 最简单的方案：用 context.pages 获取所有已打开页面

每个 BrowserContext 维护着一个当前会话内所有标签页的列表，直接调用context.pages就能拿到。这大概是最直观、最不加思考的方案了，但这玩意儿有个坑：页面列表的顺序并不总是稳定的，尤其是当你同时打开多个页面、并且有页面在后台加载时，索引顺序可能会跟你预期的不一样。

那你可能会说：我按索引取不就行了？比如context.pages[1]就算新打开的标签页，行不行？短期试运行没问题，但你很快会踩到下面这几种情况：

• 某一次点击没能成功触发新页面，context.pages的长度压根没增加，索引直接越界。
• 页面加载过快，点击后新页面已经打开，但同时旧页面因为跳转重新创建了 Page，顺序全乱。
• 扩展脚本、浏览器自身的页面（比如chrome://类型）混入 context，索引就更不可靠了。

所以我其实不太推荐直接按索引取页面。更稳妥的做法是把context.pages当做一个“备选池”，先尝试按 URL、标题、特定元素特征去匹配，实在不行再遍历所有页面做判断。下面的代码就是一个通用查找函数的标准写法，核心思想就是“不靠索引猜，靠特征认”：

from typing import Optional from playwright.sync_api import Page, BrowserContext def find_page( context: BrowserContext, *, url_contains: Optional[str] = None, title_contains: Optional[str] = None, timeout: float = 5000, ) -> Optional[Page]: """按 URL 或标题特征查找目标 Page 对象。""" start = time.time() while time.time() - start < timeout / 1000: for page in context.pages: try: if url_contains and url_contains in page.url: return page if title_contains and title_contains in page.title(): return page except Exception: # 页面可能正在关闭，跳过 continue time.sleep(0.2) return None

注意一个细节：遍历context.pages时最好给page.url和page.title()套一层异常捕获。因为页面可能正处于关窗、跳转、崩溃的中间态，访问属性时抛出的异常种类还挺多，不加保护的话，一个半死不活的页面就能让你的整个查找函数崩掉。

2.2 最推荐的方式：监听 popup 事件直接捕获新页面

真正写自动化测试和爬虫的人，最常用的其实是page.expect_popup()和context.on("page")这套事件机制。原理上它跟你用手机的人脸识别一样：在“新窗口打开”这个动作触发之前，你先把监听器注册好，等 JS 执行到window.open()的那一瞬间，Playwright 就把这个新 Page 对象直接交到你手里，连查找的步骤都省了。

看一段同步 API 的代码：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=False) context = browser.new_context() page = context.new_page() # 关键：expect_popup 必须在“可能触发新页面的操作”之前调用 with page.expect_popup() as popup_info: page.click('a[target="_blank"]') # 触发新标签页 new_page = popup_info.value new_page.wait_for_load_state("domcontentloaded") print(new_page.url) new_page.close()

这个方法最大的优势是：精准。它会把事件产生的精确 Page 对象返回给你，不存在多个页面里认错人的问题。它最大的坑则是：注册时机不能错。expect_popup()必须出现在触发点击之前，而且必须在同一段代码块里。如果你先page.click()再回头context.pages里找，很多时候也来得及，但遇到页面加载极快的情况，说不定弹出事件已经结束，你的监听器就成了马后炮。

异步 API 的写法跟同步略有不同，核心是async with page.expect_popup()，但通用的等待逻辑是一致的。我日常里更偏向用一个辅助函数把等待、自动聚焦、加载状态判断都封装好，后面第 4 章我会贴出完整封装代码。

2.3 多页面独立会话：用多个 BrowserContext 隔离

有一种特别容易混淆的场景：你以为自己需要多页面切换，实际上你需要的是多会话隔离。最典型的就是同一时间登录两个账号、分别操作两个系统。如果你只是在同一个 Context 里开两个标签页，那你的登录态、Cookie、localStorage 全是共享的——A 账号登录了，B 标签页瞬间也变成 A 账号。这显然不是你要的效果。

Playwright 的答案是用browser.new_context()创建多个独立的上下文。每个 Context 拥有完全独立的存储空间，你可以通俗地理解成“一个 Context 就是一个隐身窗口会话”。多个 Context 之间互不干扰，甚至可以在同一个 Browser 实例上并行存在。

context_a = browser.new_context() context_b = browser.new_context() page_a = context_a.new_page() page_b = context_b.new_page() # 在 context_a 里登录账号A page_a.goto("https://example.com/login") page_a.fill("#username", "user_a") page_a.fill("#password", "pass_a") page_a.click("#login") # 在 context_b 里登录账号B，互不影响 page_b.goto("https://example.com/login") page_b.fill("#username", "user_b") page_b.fill("#password", "pass_b") page_b.click("#login")

要注意的点是：多 Context 不等于多进程，它依然共享同一个浏览器进程和网络栈，所以如果你是想靠多 Context 提升性能，那帮助有限。但它对“会话隔离”“账号隔离”这件事的帮助是质变级的。还有一个实用小技巧：如果某个 Context 不再用了，记得context.close()，否则它会一直占用内存和文件句柄，跑长任务时内存只涨不降，多半就是 Context 没关干净。

2.4 页面可见性与焦点：bring_to_front 用对了吗

很多人找到目标页面之后，第一反应是“我要把它切到前台”，下意识找类似 Selenium 的switch_to.window方法。Playwright 对应的做法是page.bring_to_front()，它的作用是把这个标签页激活到前台，等价于用户点了这个标签页的页签。

但请注意，bring_to_front()并不影响页面里的 DOM 状态。有些页面在后台时会被浏览器节流（比如定时器减速、动画暂停），切到前台后会重新恢复。如果你的操作涉及复杂的 JS 等待，建议调用bring_to_front()之后再用wait_for_load_state()或者expect(locator)等待关键元素出现，千万别用time.sleep()硬等——这在多页面场景里是极其脆弱的写死逻辑。

有一个我实际踩过的坑：当页面处于后台标签页时，某些网站的滚动距离、可点击元素的可见性计算是有异常的，你用locator.click()时会报“element is not visible”或“element is outside of the viewport”。这时候两板斧：先bring_to_front()，再locator.scroll_into_view_if_needed()。顺序不能反，反了会有偶发性的失败。

3. 实战拆解：从点击到定位的完整流程

3.1 一个标准的“点击打开新页面并操作”流程

假设你今天要写的脚本是这个需求：打开电商平台搜索商品，点击其中一个商品链接（链接在新标签页打开），在商品详情页拿到价格和标题，再切回搜索页继续浏览。

很多人一上来就写两个page.goto()，但这里新商品页并不会替换原搜索页，而是会额外多出一个 Page。所以我给你一个可以照着抄的完整代码：

from playwright.sync_api import sync_playwright with sync_playwright() as p: browser = p.chromium.launch(headless=False) context = browser.new_context( viewport={"width": 1280, "height": 720}, locale="zh-CN", ) # 打开搜索页 page = context.new_page() page.goto("https://example.com/search?q=playwright", wait_until="domcontentloaded") page.wait_for_selector(".product-list") # 记录当前页面数量 print("当前页面数量:", len(context.pages)) # 点击目标商品，等待新页面打开 with context.expect_page() as new_page_info: page.click(".product-item:first-child a") # 从事件里拿到新页面对象，并等待关键内容 detail_page = new_page_info.value detail_page.wait_for_load_state("domcontentloaded") detail_page.wait_for_selector(".product-title", timeout=10000) # 切换到新页面并提取信息 detail_page.bring_to_front() title = detail_page.text_content(".product-title").strip() price = detail_page.text_content(".product-price").strip() print(f"标题: {title}") print(f"价格: {price}") # 关闭新页面，回到搜索页继续操作 detail_page.close() page.bring_to_front() page.wait_for_selector(".product-list") print("搜索页标题:", page.title())

这段代码里有两个细节值得专门拿出来说。第一个是with context.expect_page() as new_page_info，它和前面page.expect_popup()的区别在哪？expect_page()是在 Context 级别监听所有新页面创建事件，哪怕新页面不是当前页面触发的（比如后台定时器弹窗），也能捕获到；而expect_popup()只监听当前 Page 关联的弹窗事件，颗粒度更细。大多数场景两者都能用，但我建议你在“点击后必出新窗口”的场景里优先用context.expect_page()，它的包容性更强，代码健壮性也更高。

第二个细节是detail_page.wait_for_load_state("domcontentloaded")。为什么不是默认的load？因为很多电商详情页会加载大量的异步资源、埋点脚本，load事件可能等得又慢又没必要；domcontentloaded只要 DOM 树构建完成就算过，你真正要等的是.product-title元素，那一段wait_for_selector()才是精准的拦截关卡。用两级等待策略，既稳又不会白白浪费时间。

3.2 多个页面同时打开，如何迅速定位目标页

现实需求往往更扭曲一点：不是点一个链接开一个页面，而是循环点击一堆链接，新页面一个接一个地开，你要在乱七八糟的一堆标签页里精准找到“第 3 个”或者“URL 带特定参数的”那个页面。这时候事件捕获依然好用，但你需要一个更工程化的页面管理器。

我的做法是给每个目标页面打标签，用字典维护一个“业务名称 → Page 对象”的映射关系。这样可以避免每次需要某个页面时，都要从头遍历context.pages。但注意，页面对象是有生命周期的：如果某个页面被关闭了，字典里的 Page 对象就会失效，再次调用会抛异常。所以我在定位方法里加了异常重试机制：

from playwright.sync_api import BrowserContext, Page class PageHub: """简易的多页面管理器：按业务名注册/获取页面对象""" def __init__(self, context: BrowserContext): self.context = context self._pages: dict[str, Page] = {} def register(self, name: str, page: Page): self._pages[name] = page print(f"[PageHub] 注册页面: {name} -> {page.url}") def get(self, name: str, timeout: float = 5000) -> Page: import time start = time.time() while time.time() - start < timeout / 1000: page = self._pages.get(name) if page is not None: try: # 随便访问一个属性，校验页面是否还活着 _ = page.url return page except Exception: # 页面已失效，重新通过上下文查找 self._pages.pop(name, None) matching = self._find_by_name(name) if matching: return matching time.sleep(0.2) raise TimeoutError(f"页面 [{name}] 不存在或已失效") def _find_by_name(self, name: str) -> Page | None: for page in self.context.pages: if name in page.url or name in page.title(): self.register(name, page) return page return None

这套设计看着简单，但实际跑起来非常好用。你在爬虫流程里循环打开多个详情页时，每开一个页面就hub.register(f"detail_{index}", page)，等需要操作时直接用hub.get("detail_3")，完全不用管标签页的顺序、数量。多页面管理的核心从来不是“切换”这个动作，而是“如何稳定地记住你要用的是哪一个页面”——引用管理搞好了，切换就是一场顺手的事。

3.3 元素定位在哪个页面里，别搞混了

页面定位和元素定位最大的区别在于：前者是确定“哪个标签页”，后者是确定“哪个 DOM 节点”。在你拿到正确的 Page 对象之前，任何locator()都没有意义。但反过来，如果你已经拿到了正确的 Page 对象，元素定位又变成最关键的一环。

有个很常见的误区是：在context.pages[0]上定位不到元素，于是换个context.pages[1]去试，试通了就觉得很神奇。其实你只是无意中换到了正确的页面罢了。真正会出现的交叉问题是：一个页面从 URL 上看是对的（比如https://example.com/detail/123），但页面内部用了 iframe 或者 Shadow DOM，元素根本没出现在主文档里。

这时候你要搞清楚“页面定位成功”的定义。拿 iframe 举例，页面本身是定位到了，但元素还藏在 iframe 里，必须用frame_locator再深入一层：

# 假设页面里有 iframe，里面有一个登录表单 frame = detail_page.frame_locator("iframe[name='login-frame']") frame.locator("#username").fill("test") frame.locator("#password").fill("123456") frame.locator(".submit-btn").click()

另一种场景是页面用了 Shadow DOM。Playwright 对封闭式 Shadow DOM 也有原生穿透能力，locator可以自动穿透 open shadow root，但 closed shadow root 就无能为力了。真遇到 closed shadow root，我的建议是不要硬刚，优先看能不能通过页面上暴露的全局变量、接口数据或者事件监听拿到内容，毕竟自动化是为你服务的，不是让你当人肉调试器。

3.4 多上下文切换：新 context 的创建、使用与销毁

前面 2.3 节提过多个 context 做隔离，这里我再补充一点实践中非常重要的细节：context 不是越多越好。每多开一个 context，浏览器就会多一批独立的存储分区、JS 执行环境、资源加载上下文，内存开销是线性上涨的。我见过有人一次性开出 50 个 context 去跑并发，结果机器 16GB 内存直接被打满，浏览器崩溃。

如果你确实需要很多独立会话，我的建议是采用“池化复用”思路：固定创建 5~8 个 context，用完一个关一个，不用的 context 尽快归还或销毁。千万别图省事搞一次性new_context()然后扔在那里不管。另外，context.close()之后，这个 context 里所有的页面引用都会立即失效，你的 PageHub 里如果还存着这些 Page，记得同步清理，否则下次hub.get()会抛一堆莫名其妙的异常。

4. 硬核排查与避坑指南

4.1 页面切换后元素找不到？先确认页面加载状态

这是多页面场景里出现频率最高的报错，没有之一。典型症状是：新页面明明打开了，print(context.pages)里也有它，但一执行page.locator(".price").text_content()就报TimeoutError。大多数人第一反应是“选择器写错了”，其实十个里有八个是页面还没加载到你想要的内容。

你需要意识到，new_page返回时，页面可能只是刚刚创建了空白文档。尤其遇到单页应用（SPA），domcontentloaded事件触发了不代表路由渲染完成，数据可能还在异步请求中。这时候正确姿势是用 Playwright 的自动等待机制，也就是expect(locator).to_be_visible()这类断言，它会自动重试直到元素出现或者超时。写起来也就多一行：

detail_page.locator(".product-price").wait_for(state="visible", timeout=10000)

等wait_for通过之后，再执行text_content()就稳如老狗。注意我这里的顺序是先wait_for再读取，而不是直接读取。这个习惯能帮你过滤掉 80% 的偶发性失败。

4.2 链接确实点击了，但没弹出来新页面

另一个高频问题：看着代码逻辑没问题，page.click()也执行了，但context.pages的数量就是没变化。原因通常有几个方向：

• 点击被页面上的弹层拦截了。比如登录弹窗、授权弹窗、悬浮广告，page.click()虽然执行了，但实际点到的不是你要的那个链接。排查方法：点击前先判断目标元素是否可见，或者用force=True强制点击（但慎用）。
• 页面的 JS 有延时逻辑。setTimeout之后才触发window.open()，你click()完立刻查context.pages，当然查不到。正确做法是用expect_page()/expect_popup()去异步等待，事件机制能捕获到你肉眼还没看到的页面创建。
• 浏览器弹窗拦截器生效了。无头模式下某些浏览器策略会拦截非用户手势产生的window.open()，但大多数 Playwright 启动的浏览器不会触发这个策略。如果真遇到了，尝试用browser.new_context()时加上--disable-popup-blocking参数。

4.3 页面对象“幽灵引用”问题

这个坑藏得比较深。假设你有两个变量同时指向同一个 Page 对象，其中page_a过期了，但page_b还在正常使用。你操作page_a时可能会看到报错，也可能不报错，而是操作到了错误的状态——比如页面跳转之后，page_a.url已经是新地址了，但 DOM 内容可能还在旧状态。

遇到这种问题，我的排查建议是：不要凭“我以为这个页面是哪个”来做判断，每次跨页面操作前都打印一下page.url和page.title()，先验证身份再动手。如果你的脚本逻辑里经常出现变量混用，最简单的办法就是减少变量的生命周期，用完的页面立刻close()，别留一堆悬空引用。

4.4 快速排查速查表

这套速查表是长期调试多页面脚本后沉淀下来的记忆导图。你以后遇到问题可以先对应症状翻查，能省掉不少重新踩坑的时间。

5. 把定位逻辑封装成一个可以复用的工具函数

最好的经验不是停留在“我这次跑通了”，而是把这套逻辑整理成工具，让下一次可以直接抄。我这里分享一个我自己在日常项目里用了很久的页面切换工具箱，它把常见场景都包了一遍，你拿到手稍微改改就能用。

from playwright.sync_api import BrowserContext, Page, expect import time def wait_for_new_page( context: BrowserContext, trigger_action, timeout: float = 10000, ) -> Page: """ 执行一个触发器动作，并等待 Context 中出现新的页面。 适合：点击链接打开新标签页、window.open 等场景。 """ with context.expect_page(timeout=timeout) as page_info: trigger_action() new_page = page_info.value new_page.wait_for_load_state("domcontentloaded") return new_page def find_page_by_title(context: BrowserContext, title_part: str, timeout: float = 5000) -> Page: """在所有已打开页面中按标题关键字查找。""" deadline = time.time() + timeout / 1000 while time.time() < deadline: for p in context.pages: try: if title_part in p.title(): return p except Exception: continue time.sleep(0.2) raise TimeoutError(f"没有找到标题包含 [{title_part}] 的页面") def find_page_by_url(context: BrowserContext, url_part: str, timeout: float = 5000) -> Page: """在所有已打开页面中按 URL 关键字查找。""" deadline = time.time() + timeout / 1000 while time.time() < deadline: for p in context.pages: try: if url_part in p.url: return p except Exception: continue time.sleep(0.2) raise TimeoutError(f"没有找到 URL 包含 [{url_part}] 的页面") def switch_to_page(context: BrowserContext, target: Page | str, absolute: bool = False) -> Page: """ 统一入口：要么直接传入 Page 对象，要么传入 URL/标题关键字。 absolute 为 True 表示传入的是完整 URL 匹配，否则是关键字包含匹配。 """ if isinstance(target, Page): target.bring_to_front() return target try: return find_page_by_url(context, target) except TimeoutError: return find_page_by_title(context, target)

用的时候大概是这种感觉：

new_page = wait_for_new_page(context, lambda: page.click(".open-detail")) switch_to_page(context, "detail/10086") # 现在你已经稳稳定位在目标页面上了

你注意switch_to_page里的逻辑顺序：先按 URL 关键字查，查不到再按标题查。这是因为 URL 的可辨识度通常比标题高，而且标题可能因为页面渲染时序问题暂时为空。如果你预计页面中有多个 URL 都包含同一关键字，那就先自己把条件写得更严格一点，比如用正则做完整匹配。

这套工具唯一需要你留意的地方是trigger_action这个参数。它接收的是一个函数对象，所以你可以放心地把任何复杂的“点击、回车、等待”逻辑传进去，不必担心事件窗口错过。这个设计比把触发代码硬编码在函数内部要灵活得多，也是我最后想分享给你的一条心得：写测试工具时，多把“动作”和“等待”拆开，组合起来才顺手。

多页面切换和定位这件事，说穿了就是两句话：一是拿到页面引用的方式要对，二是操作前确认你手上真的是目标页面。前者靠事件监听和上下文管理解决，后者靠打印验证和状态等待保障。你在自己的项目里把这套逻辑沉淀成小工具，后面写任何多窗口爬虫、多标签 UI 测试，都会轻松很多。