Playwright启动Chromium内存高并非内核太重，而是默认启用GPU、图片加载、扩展等冗余功能；实测通过--headless=new、--disable-gpu、--disable-images、--font-render-hinting=none等参数及context复用，单页内存可从600MB+压至约120MB。
Playwright 启动 Chromium 内存占用高，根本不是浏览器“太重”，而是默认配置把所有对人友好的功能全打开了——而自动化根本用不上。实测关闭几项关键参数，单页实例内存能从 600MB+ 压到 120MB 左右。
为什么 launch() 一调用就吃掉几百 MB 内存
Playwright 默认启动的是完整版 Chromium，和你在桌面双击打开的 Chrome 几乎一样：每个 page 都会触发独立渲染进程、GPU 进程、网络服务进程、扩展加载器，甚至还会预加载字体和图片。这些在 UI 场景里提升体验的功能，在自动化里全是冗余开销。
更隐蔽的问题是：即使你只 launch() 一次，只要没显式关闭 browser 或复用 context，Playwright 就可能在后台累积 DOM 快照、CDP 缓存、JS 执行上下文，导致内存缓慢爬升。
- 默认启用 GPU 渲染 → 占用额外 100–200MB 显存 + 内存映射
- 不拦截图片/字体资源 → 一个电商页面光图片就能加载 30–50MB 原始数据
- 未限制渲染进程数 → 每个
page默认独占一个渲染进程，哪怕只跑 JS - 未禁用扩展和 infobars → 启动时仍会初始化扩展管理器和安全提示模块
launch() 必加的 4 个内存控制参数
这些参数必须写进 p.chromium.launch() 的 args 列表或直接作为关键字参数，缺一不可：
立即学习“Python免费学习笔记（深入）”；
-
--headless=new：强制新式无头模式（比旧版--headless更彻底，跳过所有 UI 子系统） -
--disable-gpu：关闭 GPU 加速（无头模式下 GPU 完全无用，且 Windows 上开启易 crash） -
--disable-images：拦截所有<img>和 CSSbackground-image请求（比在route里拦截更早、更省 CPU） -
--font-render-hinting=none：禁用字体微调，减少字体解析内存驻留
示例：
browser = p.chromium.launch(
headless=True,
args=[
"--headless=new",
"--disable-gpu",
"--disable-images",
"--font-render-hinting=none",
"--disable-extensions",
"--disable-infobars",
],
)
context 和 page 复用比 launch 更关键
很多人以为“少 launch 就省内存”，其实更大的浪费来自反复新建 context 和 page。每次 browser.new_context() 都会分配全新用户数据目录、V8 isolate、Cookie store 和缓存空间；new_page() 则额外创建渲染进程和 JS 执行环境。
- 一个
context可安全复用 50+ 次new_page()，只要任务间无登录态冲突 - 串行任务优先复用同一
context，避免频繁close()→new_context() - 并发任务若需隔离 Cookie，可用
storage_state序列化/反序列化替代全新 context - 务必手动调用
page.close()和context.close()，别依赖 GC —— Playwright 的资源清理不保证即时
Windows 上 headful 模式容易崩溃的真相
如果你非得用 headless=False（比如调试或录屏），Windows 下大概率遇到 TargetClosedError 或瞬间闪退。这不是代码问题，而是 Chromium 在有界面模式下强依赖当前 Windows 用户会话和显卡驱动状态。
稳定方案只有两个：
- 开发调试时加
chromium_sandbox=False+--disable-gpu+--no-sandbox（仅限可信环境） - 生产环境一律用
headless=True，配合screenshot()或video参数录屏取证
千万别信“加个 --start-maximized 就能稳”——这个参数反而会触发更多 UI 初始化逻辑，内存占用不降反升。
真正压内存的不是 Chromium 内核本身，而是你没关掉的那些“默认打开”的功能开关。参数设错一次，内存多占 300MB；context 多建一次，就多扛 80MB 常驻开销。这些数字在并发 10+ 实例时会直接翻倍，而不是线性增长。
