Playwright中Browser与Browser Context的区别及相关技术疑问

1. 通俗解释Browser Context，是否类似Selenium Session？ #

你可以把Browser（浏览器实例）比作一台物理电脑，Browser Context就是这台电脑上的独立用户账户——每个账户有自己专属的Cookie、本地存储、浏览器设置，和其他账户完全隔离，你在这个账户下打开的所有标签页（Page）都属于这个账户。

和Selenium的Session对比：Selenium的Session和单个浏览器实例绑定，一个浏览器实例对应一个Session；而Playwright的一个Browser可以同时存在多个Context，每个Context都是独立的“会话环境”，比Selenium新建浏览器实例高效得多（不用重复启动浏览器进程）。它更像是Selenium中“多独立会话”的轻量化实现，隔离性完全一致。

2. 既然Page是标签页，测试中开新标签页为何要新建Context？ #

首先明确：单纯开新标签页不需要新建Context，直接用page.newPage()就能在同一个Context下创建新标签页。

测试场景中常用新建Context，核心目的是状态隔离：比如模拟不同用户登录，或者确保每个测试用例都从“干净环境”开始（没有之前测试留下的Cookie、缓存）。同一个Context下的所有Page共享状态（比如登录态），而新Context是完全空白的，能彻底避免测试用例之间的污染。如果你的测试不需要隔离状态，在同一个Context开新Page完全没问题。

3. 测试间是否应该共享Context？Playwright Test的处理逻辑是怎样的？ #

绝对不建议在测试间共享Context——一旦共享，前一个测试的状态（比如登录态、缓存数据）会影响后续测试，导致测试结果不稳定，出现“偶发失败”的问题。

Playwright Test的默认逻辑是：

• 浏览器实例（Browser）会复用（因为启动浏览器进程很慢），所有测试共用一个Browser；
• 每个测试用例都会创建一个全新的Browser Context，测试结束后自动关闭这个Context；
• 这样既保证了每个测试的环境隔离，又通过复用Browser提升了测试效率。

4. 页面对象模型（POM）应该传入Page还是Context？ #

优先传入Page对象。

POM的核心是封装单个页面的交互逻辑，Page对象直接对应具体的标签页，调用它的方法（比如page.click()、page.fill()）最直接。如果你的POM需要创建新页面，也可以通过page.context()获取当前Context，再调用context.newPage()，不需要提前传入Context。

只有在少数跨页面、跨用户的复杂场景（比如POM需要同时管理多个独立页面会话），才需要传入Context，但这种情况很少见。

附加疑问：手动管理浏览器/Context的开启关闭有什么优势？ #

Playwright Test是封装好的标准化测试框架，适合大多数常规测试场景，但手动管理在这些场景下更有优势：

• 自定义工作流：比如做持续爬虫、监控任务，需要长时间保持一个Context的状态，或者按需创建/销毁Context；
• 精细控制资源：比如你需要在多个测试中共享同一个Context，但手动清理状态（比如清除Cookie），而不是每次都新建；
• 集成到非测试系统：比如把Playwright集成到后端服务中，作为接口的一部分，需要自己控制浏览器的生命周期；
• 调试场景：手动启动浏览器和Context，可以保留浏览器窗口，方便你逐步调试代码，而Playwright Test默认会关闭浏览器。

当然，手动管理需要你自己处理资源释放（比如调用context.close()、browser.close()），否则会导致内存泄漏，这是需要注意的点。

内容的提问来源于stack exchange，提问作者msmith1114