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(headlessFalse) 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(headlessFalse) context browser.new_context( viewport{width: 1280, height: 720}, localezh-CN, ) # 打开搜索页 page context.new_page() page.goto(https://example.com/search?qplaywright, wait_untildomcontentloaded) 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, timeout10000) # 切换到新页面并提取信息 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(fdetail_{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[namelogin-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返回时页面可能只是刚刚创建了空白文档。尤其遇到单页应用SPAdomcontentloaded事件触发了不代表路由渲染完成数据可能还在异步请求中。这时候正确姿势是用 Playwright 的自动等待机制也就是expect(locator).to_be_visible()这类断言它会自动重试直到元素出现或者超时。写起来也就多一行detail_page.locator(.product-price).wait_for(statevisible, timeout10000)等wait_for通过之后再执行text_content()就稳如老狗。注意我这里的顺序是先wait_for再读取而不是直接读取。这个习惯能帮你过滤掉 80% 的偶发性失败。4.2 链接确实点击了但没弹出来新页面另一个高频问题看着代码逻辑没问题page.click()也执行了但context.pages的数量就是没变化。原因通常有几个方向点击被页面上的弹层拦截了。比如登录弹窗、授权弹窗、悬浮广告page.click()虽然执行了但实际点到的不是你要的那个链接。排查方法点击前先判断目标元素是否可见或者用forceTrue强制点击但慎用。页面的 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 快速排查速查表症状可能原因解决方案优先级新页面打开了但报元素找不到页面加载未完成先用wait_for等待元素再读取内容context.pages数量没增加点击被拦截 / 弹窗延迟 / 选择器点错元素改用context.expect_page()异步监听检查点击目标是否被遮挡切换页面后操作到旧页面Page 引用混乱 / 页面跳转导致 URL 变化操作前打印 URL 和标题确认身份用 PageHub 统一管理多个标签页互相影响登录态共享 Context 存储需求为隔离时创建多个new_context()新页面加载极慢页面资源过多 / 网络慢等待策略降级为domcontentloaded再用元素级等待关闭页面后报错操作了已关闭的 Page捕获异常后从context.pages重新获取或重建页面后台页面元素不可见浏览器节流 / 视口限制先bring_to_front()再scroll_into_view_if_needed()iframe 内元素定位不到主文档中没有该元素用frame_locator()深入定位这套速查表是长期调试多页面脚本后沉淀下来的记忆导图。你以后遇到问题可以先对应症状翻查能省掉不少重新踩坑的时间。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(timeouttimeout) 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 测试都会轻松很多。