Playwright CLI on KnightLi的博客

Playwright CLI 视频录制：录屏、章节标记、Overlay 与调试对比

Wed, 15 Apr 2026 08:22:45 +0800

如果你想把浏览器自动化过程录成视频，用来做调试、文档演示，或者作为执行结果留档，Playwright CLI 已经提供了比较直接的方案。它输出的是 WebM 视频，编码为 VP8/VP9。

这篇按官方 video-recording 参考文档整理，重点包括基础录制流程、章节标记、整段 hero script 录制、Overlay API，以及 video 与 tracing 的区别。文中的命令行、代码片段与参数说明均按参考内容保留。

01 基础录制流程

最基础的流程就是：先打开浏览器，再开始录制，执行操作，最后停止并保存。

# Open browser first
playwright-cli open

# Start recording
playwright-cli video-start demo.webm

# Add a chapter marker for section transitions
playwright-cli video-chapter "Getting Started" --description="Opening the homepage" --duration=2000

# Navigate and perform actions
playwright-cli goto https://example.com
playwright-cli snapshot
playwright-cli click e1
# Add another chapter
playwright-cli video-chapter "Filling Form" --description="Entering test data" --duration=2000
playwright-cli fill e2 "test input"

# Stop and save
playwright-cli video-stop

这组命令已经覆盖了最常见的录制路径。video-chapter 适合在不同阶段之间插入章节卡片，让录出来的视频更容易看懂。

02 最佳实践

1. 使用更清晰的文件名

如果视频是给别人看，或者后面还要回查，文件名最好直接带上场景和上下文。

1
2
3

# Include context in filename
playwright-cli video-start recordings/login-flow-2024-01-15.webm
playwright-cli video-start recordings/checkout-test-run-42.webm

2. 录制完整 hero script

官方建议：如果视频是要交付给用户，或者要作为 proof of work，最好把场景整理成一段代码，然后用 run-code 执行。这样更容易控制动作节奏、停顿时机，以及视频里的标注效果。参考文档也特别提到，Playwright 新增了一些适合录制场景的 API。

推荐流程如下：

先用 CLI 走一遍场景，并记下所有 locator 和 action。后面如果要做高亮，需要用这些 locator 去请求它们的 bounding box。
为视频单独创建一个脚本文件，并按下面的方式编写。输入内容时用 pressSequentially 配合 delay，停顿时间也尽量安排得自然。
使用 playwright-cli run-code --filename your-script.js 执行。

Important: Overlays are pointer-events: none — they do not interfere with page interactions. You can safely keep sticky overlays visible while clicking, filling, or performing any actions on the page.

async page => {
  await page.screencast.start({ path: 'video.webm', size: { width: 1280, height: 800 } });
  await page.goto('https://demo.playwright.dev/todomvc');
  // Show a chapter card — blurs the page and shows a dialog.
  // Blocks until duration expires, then auto-removes.
  // Use this for simple use cases, but always feel free to hand-craft your own beautiful
  // overlay via await page.screencast.showOverlay().
  await page.screencast.showChapter('Adding Todo Items', {
    description: 'We will add several items to the todo list.',
    duration: 2000,
  });
  // Perform action
  await page.getByRole('textbox', { name: 'What needs to be done?' }).pressSequentially('Walk the dog', { delay: 60 });
  await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter');
  await page.waitForTimeout(1000);

  // Show next chapter
  await page.screencast.showChapter('Verifying Results', {
    description: 'Checking the item appeared in the list.',
    duration: 2000,
  });
  // Add a sticky annotation that stays while you perform actions.
  // Overlays are pointer-events: none, so they won't block clicks.
  const annotation = await page.screencast.showOverlay(`
    <div style="position: absolute; top: 8px; right: 8px;
      padding: 6px 12px; background: rgba(0,0,0,0.7);
      border-radius: 8px; font-size: 13px; color: white;">
      ✓ Item added successfully
    </div>
  `);
  // Perform more actions while the annotation is visible
  await page.getByRole('textbox', { name: 'What needs to be done?' }).pressSequentially('Buy groceries', { delay: 60 });
  await page.getByRole('textbox', { name: 'What needs to be done?' }).press('Enter');
  await page.waitForTimeout(1500);

  // Remove the annotation when done
  await annotation.dispose();
  // You can also highlight relevant locators and provide contextual annotations.
  const bounds = await page.getByText('Walk the dog').boundingBox();
  await page.screencast.showOverlay(`
    <div style="position: absolute;
      top: ${bounds.y}px;
      left: ${bounds.x}px;
      width: ${bounds.width}px;
      height: ${bounds.height}px;
      border: 1px solid red;">
    </div>
    <div style="position: absolute;
      top: ${bounds.y + bounds.height + 5}px;
      left: ${bounds.x + bounds.width / 2}px;
      transform: translateX(-50%);
      padding: 6px;
      background: #808080;
      border-radius: 10px;
      font-size: 14px;
      color: white;">Check it out, it is right above this text
    </div>
  `, { duration: 2000 });
  await page.screencast.stop();
}

这一段代码的重点不只是“录下来”，而是把视频做得更清楚：章节卡片负责分段，pressSequentially 让输入动作更自然，showOverlay 则可以做提示、高亮和说明。

文档最后还补了一句：Embrace creativity, overlays are powerful.

03 Overlay API 速览

录制视频时，Overlay API 很适合做章节切换、局部提示和持续注释。官方给出的摘要如下：

Method	Use Case
`page.screencast.showChapter(title, { description?, duration?, styleSheet? })`	Full-screen chapter card with blurred backdrop — ideal for section transitions
`page.screencast.showOverlay(html, { duration? })`	Custom HTML overlay — use for callouts, labels, highlights
`disposable.dispose()`	Remove a sticky overlay added without duration
`page.screencast.hideOverlays()` / `page.screencast.showOverlays()`	Temporarily hide/show all overlays

如果你的目标是把自动化过程做成“可观看的视频”，这一组 API 基本就是最值得优先掌握的部分。

04 Tracing 和 Video 的区别

官方文档把两者的定位区分得很清楚：

Feature	Video	Tracing
Output	WebM file	Trace file (viewable in Trace Viewer)
Shows	Visual recording	DOM snapshots, network, console, actions
Use case	Demos, documentation	Debugging, analysis
Size	Larger	Smaller

简单理解：

video 更适合演示、交付和复盘“用户看到的过程”
tracing 更适合排查问题、分析动作细节和查看执行上下文

这两者并不是互相替代，而是各自服务于不同目标。

05 使用限制

文档里也提醒了两个很实际的限制：

Recording adds slight overhead to automation
Large recordings can consume significant disk space

也就是说，录制功能虽然很实用，但会给自动化流程增加一些开销；如果视频很长，磁盘占用也会明显上升。

06 快速总结

如果只抓重点，可以记住下面几件事：

video-start / video-stop 对应最基本的视频录制流程
video-chapter 可以给视频加章节过渡，适合让演示更清晰
更复杂的视频场景，适合写成脚本后用 run-code 执行
showOverlay 和 showChapter 可以显著提升视频的可读性
video 适合演示，tracing 适合调试，两者最好按目标选择

如果你已经在用 Playwright CLI 做自动化演示、验收留档或 proof of work，那么 video recording 会是一块非常值得补上的能力。

参考链接

Playwright CLI video-recording 参考文档：https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/video-recording.md
Playwright CLI 项目主页：https://github.com/microsoft/playwright-cli

Playwright CLI 会话管理：多浏览器会话、隔离、持久化与清理

Wed, 15 Apr 2026 08:15:12 +0800

如果你在用 Playwright CLI 做自动化，很快就会碰到一个实际问题：同一时间里，能不能开多个互不干扰的浏览器会话？答案是可以，而且 Playwright CLI 已经把这套机制做得很直接。

这篇就按照官方 session-management 参考文档，整理它最实用的几部分：命名会话、会话隔离、持久化 profile、并发模式，以及常见清理命令。文中的命令行与命令块说明均按参考内容保留。

01 命名浏览器会话

官方建议用 -s 参数隔离不同浏览器上下文：

# Browser 1: Authentication flow
playwright-cli -s=auth open https://app.example.com/login

# Browser 2: Public browsing (separate cookies, storage)
playwright-cli -s=public open https://example.com

# Commands are isolated by browser session
playwright-cli -s=auth fill e1 "user@example.com"
playwright-cli -s=public snapshot

这里的重点是：不同 session 名称对应不同浏览器上下文。你可以把 auth 用在登录流程，把 public 用在匿名访问，它们之间不会共用 cookies 或本地状态。

02 浏览器会话隔离了什么

每个浏览器会话都会独立维护下面这些内容：

Cookies
LocalStorage / SessionStorage
IndexedDB
Cache
Browsing history
Open tabs

这意味着如果你在 auth 会话里登录了某个网站，并不会自动影响 public 会话。做多账号测试、登录态验证、匿名对比时，这一点尤其重要。

03 浏览器会话相关命令

官方文档把会话管理里最常用的一组命令放在了一起：

# List all browser sessions
playwright-cli list

# Stop a browser session (close the browser)
playwright-cli close                 # stop the default browser
playwright-cli -s=mysession close   # stop a named browser

# Stop all browser sessions
playwright-cli close-all

# Forcefully kill all daemon processes (for stale/zombie processes)
playwright-cli kill-all

# Delete browser session user data (profile directory)
playwright-cli delete-data              # delete default browser data
playwright-cli -s=mysession delete-data # delete named browser data

可以把它们理解成三类操作：

list：看当前有哪些会话
close / close-all / kill-all：结束会话或清理卡住的浏览器进程
delete-data：删除某个会话对应的用户数据目录

如果你只是结束浏览器，通常先用 close；如果已经出现残留进程或僵尸进程，再用 kill-all 会更合适。

04 用环境变量设置默认会话

如果你不想每条命令都重复写 -s=mysession，官方还提供了环境变量方式：

1
2

export PLAYWRIGHT_CLI_SESSION="mysession"
playwright-cli open example.com  # Uses "mysession" automatically

这样之后不显式指定 -s 时，命令就会默认使用 mysession 这个浏览器会话。

05 常见模式：并发抓取

参考文档给了一个很典型的并发抓取例子：

#!/bin/bash
# Scrape multiple sites concurrently

# Start all browsers
playwright-cli -s=site1 open https://site1.com &
playwright-cli -s=site2 open https://site2.com &
playwright-cli -s=site3 open https://site3.com &
wait

# Take snapshots from each
playwright-cli -s=site1 snapshot
playwright-cli -s=site2 snapshot
playwright-cli -s=site3 snapshot

# Cleanup
playwright-cli close-all

这个模式适合同时打开多个站点，各自抓取页面状态，再统一清理。因为每个站点都跑在独立会话里，所以不会互相污染本地状态。

06 常见模式：A/B 测试会话

另一个常见场景，是同时对比不同实验版本：

# Test different user experiences
playwright-cli -s=variant-a open "https://app.com?variant=a"
playwright-cli -s=variant-b open "https://app.com?variant=b"

# Compare
playwright-cli -s=variant-a screenshot
playwright-cli -s=variant-b screenshot

这种写法很适合做 A/B 页面差异对比，因为两个版本在独立会话里运行，截图和状态检查也更容易分开管理。

07 持久化浏览器 profile

官方文档特别说明：默认情况下，浏览器 profile 只保存在内存里。

如果你希望把浏览器 profile 持久化到磁盘，需要在 open 时加上 --persistent：

# Use persistent profile (auto-generated location)
playwright-cli open https://example.com --persistent

# Use persistent profile with custom directory
playwright-cli open https://example.com --profile=/path/to/profile

这个能力适合需要长期复用登录态、本地缓存或扩展调试环境的场景。尤其在反复调试同一站点时，持久化 profile 往往会比每次从零开始更高效。

08 默认浏览器会话

如果没有显式传入 -s，那么命令会使用默认浏览器会话：

# These use the same default browser session
playwright-cli open https://example.com
playwright-cli snapshot
playwright-cli close  # Stops default browser

也就是说，不带 -s 的几条命令默认是在同一个默认会话里连续执行的。

09 打开时附带会话配置

除了会话名，官方也给出了几种常见的启动配置方式：

# Open with config file
playwright-cli open https://example.com --config=.playwright/my-cli.json

# Open with specific browser
playwright-cli open https://example.com --browser=firefox

# Open in headed mode
playwright-cli open https://example.com --headed

# Open with persistent profile
playwright-cli open https://example.com --persistent

这些参数可以和会话管理一起配合使用。比如你可以让某个命名会话固定跑在 firefox，或者让某个会话始终以 headed 模式启动，方便人工观察。

10 官方给出的最佳实践

参考文档列了三条很实用的最佳实践。

1. 用有语义的会话名

# GOOD: Clear purpose
playwright-cli -s=github-auth open https://github.com
playwright-cli -s=docs-scrape open https://docs.example.com

# AVOID: Generic names
playwright-cli -s=s1 open https://github.com

会话名最好能直接表达用途。像 github-auth、docs-scrape 这种名字，后面维护脚本时会清楚很多。

2. 用完及时清理

# Stop browsers when done
playwright-cli -s=auth close
playwright-cli -s=scrape close

# Or stop all at once
playwright-cli close-all

# If browsers become unresponsive or zombie processes remain
playwright-cli kill-all

如果任务结束后不关浏览器，会话和后台进程会一直留着。短期看问题不大，但任务一多，很容易把环境弄乱。

3. 删除陈旧浏览器数据

1
2

# Remove old browser data to free disk space
playwright-cli -s=oldsession delete-data

当某些旧会话已经不用时，删除对应数据目录可以节省磁盘空间，也能避免后面误用过期状态。

11 快速总结

如果只抓重点，可以记住下面这几件事：

-s=<name> 用来创建并使用独立浏览器会话
不同会话之间会隔离 cookies、各种存储、缓存、历史记录和标签页
close-all 适合统一关闭，kill-all 适合处理异常残留进程
--persistent 用来把 profile 落盘，适合长期复用状态
会话名尽量语义化，旧数据定期清理

如果你的工作流里已经有登录态复用、多账号并行、A/B 对比或批量抓取需求，那么 session management 基本就是 Playwright CLI 里最值得先掌握的一块能力。

参考链接

Playwright CLI session-management 参考文档：https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/session-management.md
Playwright CLI 项目主页：https://github.com/microsoft/playwright-cli

Playwright CLI storage state 用法：保存登录态、读取 Cookies 与本地存储

Tue, 14 Apr 2026 22:19:55 +0800

如果你用 Playwright CLI 做浏览器自动化，storage state 基本就是最常用的能力之一。它的作用很直接：把当前浏览器里的登录态和本地状态保存下来，后面继续复用，避免每次都重新登录。

01 保存当前 storage state

最常见的场景，就是先登录一次，再把当前状态导出到文件。

`1`	`playwright-cli storage-state save auth.json`

这条命令会把当前浏览器上下文中的状态保存到 auth.json。后面如果想复用登录态，通常就是从这一步开始。

02 加载已有 storage state

已经有状态文件后，可以在启动时直接加载。

`1`	`playwright-cli --storage-state auth.json`

它会用 auth.json 里的状态启动浏览器上下文。常见用途就是跳过重复登录，直接进入已登录环境。

03 查看当前 cookies

如果你只是想确认当前会话里到底有哪些 cookies，可以直接查看。

`1`	`playwright-cli cookies`

这条命令会列出当前上下文中的 cookies。适合排查登录态是否存在、cookie 是否写入成功。

04 设置 cookies

如果你已经有 cookie 数据，也可以直接写入。

`1`	`playwright-cli cookies set '[{"name":"session","value":"abc","domain":"example.com","path":"/"}]'`

这个用法适合调试鉴权、复现特定会话，或者在脚本前手动注入 cookie 条件。

05 读取 localStorage

有些站点的登录态或前端状态不只在 cookies 里，也会放在 localStorage。

`1`	`playwright-cli local-storage`

这条命令用于查看当前页面的 localStorage 内容。排查“明明像是登录了，但页面行为不对”时，这一步很有用。

06 写入 localStorage

如果需要模拟某些前端状态，也可以直接设置。

`1`	`playwright-cli local-storage set token abc123`

它会把指定键值写入 localStorage。常见用途是注入 token、偏好配置或某些前端开关。

07 读取 sessionStorage

sessionStorage 适合看当前会话里的临时状态。

`1`	`playwright-cli session-storage`

这条命令会输出当前页面的 sessionStorage。如果某个页面逻辑依赖一次性会话数据，可以从这里检查。

08 写入 sessionStorage

需要时，也可以手动设置 sessionStorage。

`1`	`playwright-cli session-storage set key value`

它适合复现某些依赖临时状态的页面行为，或者补齐初始化步骤需要的字段。

09 查看 IndexedDB

对于更重的 Web 应用，真正关键的数据可能在 IndexedDB 里。

`1`	`playwright-cli indexed-db`

这条命令用于查看当前页面的 IndexedDB 数据。遇到复杂单页应用、离线缓存或本地数据库式状态时，可以优先检查这里。

10 一个最实用的工作流

如果你只是想稳定复用登录态，最简单的流程通常是这样：

先打开站点并手动完成登录。
执行下面这条命令保存状态：

`1`	`playwright-cli storage-state save auth.json`

后续运行时直接加载：

`1`	`playwright-cli --storage-state auth.json`

如果加载后页面还是异常，再继续检查：

playwright-cli cookies
playwright-cli local-storage
playwright-cli session-storage
playwright-cli indexed-db

这个顺序已经能覆盖大部分“状态没恢复完整”的问题。

11 使用时要注意什么

有三点最值得注意：

storage state 文件本质上是敏感数据，里面可能包含登录 cookie 或 token，不要随便提交到仓库。
只恢复 cookies 不一定够，很多现代站点还依赖 localStorage、sessionStorage 或 IndexedDB。
状态文件不是永久有效，cookie 过期、账户变更或环境切换后，通常都要重新生成。

12 快速总结

如果只记一句话：

Playwright CLI 的 storage state，就是把浏览器当前状态保存下来，再在后续任务里继续用。

而在实际排查里，最常用的一组命令就是这些：

playwright-cli storage-state save auth.json
playwright-cli --storage-state auth.json
playwright-cli cookies
playwright-cli local-storage
playwright-cli session-storage
playwright-cli indexed-db

先保存，再加载；如果不对，再分层检查 cookies 和各类本地存储，基本就是这份参考文档最实用的部分。

参考链接

Playwright CLI storage-state 参考文档：https://github.com/microsoft/playwright-cli/blob/main/skills/playwright-cli/references/storage-state.md
Playwright CLI 项目主页：https://github.com/microsoft/playwright-cli

Playwright CLI 使用入门：安装、Skills、会话管理与常用命令

Sun, 12 Apr 2026 14:36:58 +0800

如果你最近在用 Claude Code、GitHub Copilot 或其他 coding agent 做浏览器自动化，microsoft/playwright-cli 是一个很值得关注的新工具。它不是传统意义上那个“给人手动敲命令用”的浏览器小工具，而是一个面向 coding agent 的 Playwright CLI，强调的是更低 token 开销、更轻量的命令接口，以及和 Skills 工作流的结合。

从官方 README 来看，Playwright CLI 的核心思路很明确：相比 MCP 把大量工具 schema 和页面结构塞进模型上下文，CLI 命令方式更紧凑，更适合在大代码库、测试任务和浏览器自动化之间来回切换的 agent 工作流。

01 Playwright CLI 是什么

playwright-cli 是微软开源的一个 Playwright 命令行工具，官方描述是 “CLI for common Playwright actions”。它主要用来完成这些事情：

打开页面并驱动浏览器
记录和生成 Playwright 代码
抓取页面快照，获取元素引用
截图、导出 PDF
配合 coding agent 进行自动化测试和网页操作

当前 GitHub README 里把它定位得非常明确：如果你正在使用 coding agents，CLI 往往比 Playwright MCP 更合适；如果你更需要持久状态、丰富 introspection 和长时间 agentic loop，MCP 仍然有它的价值。

换句话说，Playwright CLI 更像“给 AI 编码助手准备的浏览器自动化接口”，而不只是给人类工程师手动点击网页的工具。

02 它的优点在哪里

1. 更适合 agent 工作流

官方 README 把第一优点直接写成了 Token-efficient。它不会强制把整页数据都塞进 LLM 上下文，而是通过更短、更专用的命令让 agent 操作浏览器。

这对 coding agent 很重要。因为在真实项目里，agent 不只是跑浏览器，还要看代码、改文件、跑测试、读日志。如果浏览器工具本身就很“吃上下文”，整体效率会明显下降。

2. 能和 Skills 一起工作

README 里专门强调了 playwright-cli install --skills。这说明官方不是把它当单纯的 shell 工具来做，而是把它设计成可以被 Claude Code、GitHub Copilot 等 agent 直接消费的技能入口。

如果你的工作流本身就建立在 Skills 之上，那 Playwright CLI 的接入会更自然。

3. 会话管理做得比较完整

Playwright CLI 支持 session。默认情况下，浏览器 profile 保存在内存里，同一个 session 里的 cookies 和 storage 会在多次 CLI 调用之间保留；如果加上 --persistent，还可以把 profile 落到磁盘，跨浏览器重启继续使用。

这让它比“一条命令打开浏览器，跑完就丢”的玩具型工具更实用，也更适合持续调试和 agent 长流程执行。

4. 自带可视化监控面板

README 里提供了 playwright-cli show，用于打开一个 dashboard，观察和控制所有运行中的浏览器 session。对于 agent 在后台跑自动化任务的场景，这一点很有价值，因为你可以随时接管、观察、排错，而不是只能盲跑。

03 安装与环境要求

根据当前 GitHub README，Playwright CLI 的基本要求是：

Node.js 18 或更高版本
Claude Code、GitHub Copilot 或其他 coding agent

安装命令如下：

1
2

npm install -g @playwright/cli@latest
playwright-cli --help

这里有个很容易踩坑的地方要特别注意：

官方当前推荐安装的是 @playwright/cli
不要把它和 npm 上历史遗留、已废弃的旧包 playwright-cli 混为一谈

也就是说，真正应该装的是 scoped package，而不是旧时代的同名历史包。

04 如何开始用

1. 安装 skills

如果你希望让 coding agent 直接使用 Playwright CLI，官方建议先安装 skills：

`1`	`playwright-cli install --skills`

README 里明确写到，Claude Code、GitHub Copilot 等工具会使用本地安装的 skills。

2. 直接让 agent 调用 CLI

如果你不想先处理 skills，也可以直接让 agent 读取 CLI 帮助信息：

1
2

Test the "add todo" flow on https://demo.playwright.dev/todomvc using playwright-cli.
Check playwright-cli --help for available commands.

官方把这种方式叫做 “Skills-less operation”。意思是即使不预先装 skill，也可以通过 CLI 自描述能力来驱动 agent。

3. 手动体验一遍最小流程

README 里给了一组很适合上手的 TodoMVC 示例：

playwright-cli open https://demo.playwright.dev/todomvc/ --headed
playwright-cli type "Buy groceries"
playwright-cli press Enter
playwright-cli type "Water flowers"
playwright-cli press Enter
playwright-cli check e21
playwright-cli check e35
playwright-cli screenshot

这组命令的价值在于，它能让你很快理解 Playwright CLI 的交互方式：

open 负责打开页面
type 和 press 负责输入
check 用元素引用操作复选框
screenshot 保存结果

05 `--headed`、session 和监控面板

`--headed`

Playwright CLI 默认是 headless 的。如果你想直接看到浏览器窗口，需要在 open 时显式加上 --headed：

`1`	`playwright-cli open https://playwright.dev --headed`

这对于调试选择器、登录流程、验证码前后的交互观察会更方便。

session

官方 README 里强调了 session 的用法。你可以用不同 session 把不同项目或网站隔离开来：

1
2
3

playwright-cli open https://playwright.dev
playwright-cli -s=example open https://example.com --persistent
playwright-cli list

如果你是让 agent 长时间工作，还可以直接给它指定环境变量：

`1`	`PLAYWRIGHT_CLI_SESSION=todo-app claude .`

常用的 session 管理命令包括：

1
2
3

playwright-cli list
playwright-cli close-all
playwright-cli kill-all

其中：

list 用来列出所有 session
close-all 用来正常关闭所有浏览器
kill-all 用来强制杀掉所有浏览器进程

监控面板

如果你想看 agent 当前到底在浏览器里做了什么，可以运行：

`1`	`playwright-cli show`

按照 README 的说明，这个 dashboard 主要有两种视图：

Session grid：按 workspace 查看所有活动 session，带实时画面、URL 和页面标题
Session detail：查看单个 session 的实时界面，还能接管鼠标和键盘

这让 Playwright CLI 不只是“命令行可用”，而是具备了比较成熟的可观测性。

06 常用命令先记住哪些

如果你第一次接触 Playwright CLI，不需要一开始就把所有命令背下来。先记下面这些最核心的就够了：

页面与交互

playwright-cli open [url]
playwright-cli goto <url>
playwright-cli click <ref>
playwright-cli fill <ref> <text>
playwright-cli type <text>
playwright-cli hover <ref>
playwright-cli press <key>

获取页面结构

playwright-cli snapshot
playwright-cli snapshot <ref>
playwright-cli snapshot --depth=N
playwright-cli eval <func> [ref]

snapshot 很关键，因为很多后续操作都依赖元素引用 ref。你通常会先抓一次快照，再用返回的元素编号去点、填、勾选或截图。

输出结果

1
2

playwright-cli screenshot
playwright-cli pdf

标签页

playwright-cli tab-list
playwright-cli tab-new [url]
playwright-cli tab-close [index]
playwright-cli tab-select <index>

07 它适合谁

如果你属于下面这些场景，Playwright CLI 会很值得试：

你在用 Claude Code、Copilot 或其他 coding agent 做 E2E 测试
你希望浏览器自动化接口更轻量，不想把大量页面结构塞进上下文
你希望同一个浏览器 session 能跨多次命令持续存在
你想在 agent 自动跑网页任务时，随时打开监控面板观察进度

如果你的工作重点是“浏览器自动化如何与 coding agent 高效配合”，Playwright CLI 很可能会比传统的人类手动调试方式更顺手。

Playwright CLI on KnightLi的博客

Playwright CLI 视频录制：录屏、章节标记、Overlay 与调试对比

01 基础录制流程

02 最佳实践

1. 使用更清晰的文件名

2. 录制完整 hero script

03 Overlay API 速览

04 Tracing 和 Video 的区别

05 使用限制

06 快速总结

参考链接

Playwright CLI 会话管理：多浏览器会话、隔离、持久化与清理

01 命名浏览器会话

02 浏览器会话隔离了什么

03 浏览器会话相关命令

04 用环境变量设置默认会话

05 常见模式：并发抓取

06 常见模式：A/B 测试会话

07 持久化浏览器 profile

08 默认浏览器会话

09 打开时附带会话配置

10 官方给出的最佳实践

1. 用有语义的会话名

2. 用完及时清理

3. 删除陈旧浏览器数据

11 快速总结

参考链接

Playwright CLI storage state 用法：保存登录态、读取 Cookies 与本地存储

01 保存当前 storage state

02 加载已有 storage state

03 查看当前 cookies

04 设置 cookies

05 读取 localStorage

06 写入 localStorage

07 读取 sessionStorage

08 写入 sessionStorage

09 查看 IndexedDB

10 一个最实用的工作流

11 使用时要注意什么

12 快速总结

参考链接

Playwright CLI 使用入门：安装、Skills、会话管理与常用命令

01 Playwright CLI 是什么

02 它的优点在哪里

1. 更适合 agent 工作流

2. 能和 Skills 一起工作

3. 会话管理做得比较完整

4. 自带可视化监控面板

03 安装与环境要求

04 如何开始用

1. 安装 skills

2. 直接让 agent 调用 CLI

3. 手动体验一遍最小流程

05 --headed、session 和监控面板

--headed

session

监控面板

06 常用命令先记住哪些

页面与交互

获取页面结构

输出结果

标签页

07 它适合谁

参考链接

05 `--headed`、session 和监控面板

`--headed`