如果要问我哪个MCP使用最频繁，Playwright MCP一定榜上有名。但是在使用过程中，经常会遇到一个让人头疼的问题——多实例并发时的各种报错。本文将深入分析问题根源，并给出一劳永逸的解决方案。

一、Playwright MCP为什么这么香？

Playwright MCP将Playwright浏览器引擎包装成可被外部调用的服务，让AI Agent、IDE、自动化平台能够统一调用浏览器进行各种操作：

•页面导航：自动打开网页、跳转链接

•交互操作：点击按钮、填写表单、上传文件

•数据采集：截图、提取内容、监控变化

•自动化测试：端到端测试、回归测试

相比传统的Selenium或Puppeteer硬编码方式，MCP的优势非常明显：

1.多客户端连接：多人、多脚本可以共享浏览器实例

2.灵活并发：适合分布式任务、CI/CD并行测试

3.低门槛高复用：配置一次，到处使用

我平时用Claude Code开发完新功能或修复Bug后，都会调用Playwright MCP进行全面的端到端测试，提前发现潜在问题。为此还专门创建了SKILL来指导AI如何测试、如何发现问题。

二、那些让人崩溃的报错

正因为使用频繁，加上经常需要多任务并发，问题也随之暴露——特别是当开发者不注意隔离时，以下报错你一定不陌生：

1."Browser already in use"错误

这是最常见的报错：

Error:Browser is already in use for...
use--isolated to run multiple instances of the same browser

更离谱的是，有时在一个 全新环境 （新容器、新机器）中首次执行，就立刻失败——根本不存在"之前打开的浏览器实例"。

问题的本质是： Playwright MCP默认把所有实例都指向同一个浏览器缓存目录 。当MCP启动时会尝试"锁定"这个目录，如果另一个实例也试图启动，就触发冲突，报错退出。

有时候你会陷入这样的死循环：反复打开新窗口→失败→再打开→再失败……无论删缓存、重启VS Code、杀进程，错误依旧。

2.不断开新窗口的异常行为

即使没有报"already in use"错误，MCP在多次调用时，有时会：

•不断打开新页面、新Tab、新窗口

•旧的页面没有被正确关闭

•浏览器资源泄漏，性能急剧下降

•最终内存耗尽或句柄用完

这在做自动化测试、批量爬取、大规模操作时尤其明显。

3.Headless模式无响应

有时表现为headless模式启动后"什么都没发生"——脚本显示运行成功，但实际上浏览器根本没动作。这种"运行成功↔实际没起作用"的不一致，让调试变得极其痛苦。

三、问题根源：共享Profile的锁机制

要理解这些问题，得先懂Playwright启动浏览器的机制：

当Playwright（或通过MCP）启动浏览器时，默认会创建一个 用户数据目录（user-data-dir） ，用来存储：

•Cookies和Session

•LocalStorage数据

•浏览器扩展

•缓存文件

关键问题在于 ：MCP默认使用一个 统一的共享数据目录 。

这意味着所有通过MCP启动的浏览器实例，都会尝试读写同一个目录。在并发或多实例调用时：

•锁冲突：多个进程争抢同一个profile→"already in use"

•状态污染：Cookie、Session被覆盖→行为异常

•资源泄漏：窗口没有正确关闭→内存耗尽

一句话总结：问题的根本是"共享profile+并发调用"的冲突。

四、终极解决方案：--isolated参数

基于上述分析，最稳健、简洁、一劳永逸的方式是：

1.用户级配置：将Playwright MCP配置为全局（user-scope），而不是每个项目单独配置

2.启用隔离模式：添加--isolated参数，让每次启动都使用独立的profile