Playwright和Selenium在代理集成上差在哪，以及什么时候该迁

如果你的采集架构里"切代理"是一个高频操作：比如每个会话走不同出口、比如多账号并行跑不同 IP：从 Selenium 迁到 Playwright 的收益是确定性的。不是那种"理论上更快"的收益，是内存开销、代码复杂度、运维成本三个层面一起降的收益。

只不过，如果你的场景很简单：一个代理挂着跑到底，也不需要认证：那先别动。稳定的系统不要为了架构"更优"去折腾它。

下面拆开说。

最核心的差距在"粒度"

Selenium 的代理绑在浏览器实例上。Chrome 用 --proxy-server 启动参数，Firefox 走 profile preferences，写法不一样，但本质相同：浏览器进程一旦起来，这个代理就钉死了。想换代理怎么办？杀进程，重新起。

我们工作室 2024 年 12 月刚搭起来的时候，头两个月用的还是 Selenium，跑法律文书的增量采集。那会儿需要每个采集任务走不同出口 IP：并不是什么复杂需求，就是普通的 IP 轮换。但在 Selenium 架构下，每换一次 IP 就得关浏览器再开，冷启动一次大概 3 到 5 秒，还得重新加载 Cookie、重新渲染页面。跑 10 个并发任务，就是 10 个浏览器进程，我那台 32G 的工作站，光浏览器就吃掉 4G 多内存。当时杭州连着下了快两周的雨，我坐在望江南那间合租房的客厅里，对着 htop 里 10 个 Chrome 进程的驻留内存发呆：心想这玩意儿肯定有更合理的解法。

Playwright 多了一层叫 BrowserContext 的东西。同一个浏览器进程里可以开多个 Context，每个 Context 独立设代理。语法上三个引擎：Chromium、Firefox、WebKit：完全统一，就一个 proxy: { server, username, password } 的配置对象搞定。

说白了，隔离单元不一样：Selenium 的隔离单元是进程，Playwright 的隔离单元是 Context。

后来迁到 Playwright，同样 10 个并发任务，1 个浏览器进程加 10 个 Context，内存从 4G 多降到 1G 出头。代理切换也不用重启：关掉旧 Context、开个新的，毫秒级。

这事儿往细了讲，差距会随着并发量放大。你跑 10 个任务可能还觉得"多开几个 Chrome 也行"，等到 50、100 个并发往上走的时候，进程级隔离的内存开销和启动延迟就不是"能忍"的问题了，是架构瓶颈。

认证代理这个痛点

写过两年 Selenium 代理集成的人都懂这个痛。

HTTP 代理如果带用户名密码：就是 username:password@host:port 这种：Selenium 原生不支持认证。你得绕。

最常用的绕法是动态生成一个 Chrome Extension，把认证信息注入进去。能用，但很 hack。headless 模式下偶尔抽风，Chrome 版本一升级还可能失效。2023 年下半年那波 Manifest V2 到 V3 的过渡期，我记得 GitHub Issues 和 StackOverflow 上到处是"代理认证扩展突然不工作了"的帖子。当时我还在智谱，组里一个同事花了两天才把那套 Extension 的兼容性修好：改完他跟我说了句"这种代码我不想再维护第二次"。

另一个方案是在本地起一个无认证的中转代理，比如 mitmproxy 或者 tinyproxy，让它去对接上游带认证的隧道。多了一跳，多了一层部署、一层监控、一层可能出问题的环节。

Playwright 这块就很直接。proxy 配置里写 username 和 password，包括 SOCKS5 认证也原生支持，不需要中间层。

如果你用的是隧道代理：几乎所有隧道代理都走用户名密码认证：这一点本身就够成为迁移理由了，Playwright 配好 proxy 对象直接上，没什么额外的事。

几个跑起来才感知到的差异

SOCKS5 这块。Selenium 的 Chrome 可以用 --proxy-server=socks5://...，不带认证的话能跑。但 SOCKS5 一旦要认证，又回到 Extension 那条老路上了。Playwright 原生支持，包括认证，没什么好多说的。

跨浏览器一致性。如果你的采集策略里有"切浏览器指纹"的需求：一部分请求走 Chromium，一部分走 Firefox 做差异化：Selenium 的代理配置在两个引擎之间是两套语法。Chrome 用启动参数 args，Firefox 用 profile preference，你得维护两套。Playwright 不管用哪个引擎，proxy 配置都是同一个接口，这个维护差距长期看不小。

错误处理粒度。Playwright 在 Context 层面能精确捕获代理连接失败的事件：是代理本身超时、还是代理连上了但目标站点拒绝了、还是认证没过，这三种情况你能分开处理。Selenium 这层信息拿起来更费劲，通常得从浏览器日志里解析，粒度粗，排障慢。

什么时候该迁

频繁切换代理。这是最明确的信号。多账号管理、每个会话走不同出口、IP 用完即弃的采集模式：Selenium 切一次代理等于杀进程重启，Playwright 新建一个 Context 就完事。你一天切几千次的话，省掉的启动时间和内存是可以算出来的。

在用认证代理但被 Extension 方案折腾够了。隧道代理基本都是认证制，Playwright 能直接干掉那一整层中间件。

对资源敏感。跑在容器或者云函数里，单实例内存差 3 到 4 倍不是小事，直接影响部署密度和成本。

需要跨浏览器一致的代理行为。维护一套配置比维护两套舒服，这个不用多说。

什么时候别动

现有 Selenium 方案跑得稳、代理不需要认证、也不频繁切换：没必要迁。真的。

你依赖 Selenium Grid 做分布式调度。Playwright 这边也有方案，但生态厚度和 Grid 比差一档，尤其是大规模集群管理的周边工具链。

团队对 Selenium 的调试经验积累很深。迁移不只是改代码，是改团队的排障肌肉记忆：Selenium 的报错信息长什么样、日志怎么看、哪些坑见过怎么绕，这些经验到 Playwright 那边得重新攒。这个隐性成本要算进去。

怎么权衡，得看你自己的业务量级和团队现状。没有哪种架构是"无条件更好"的，只有适不适合当下这个阶段。