Browser Automation on 扎塔-Zata

扩展式 RPA：从 Chrome 扩展原理到 Playwright 实战方案

Mon, 27 Jul 2026 10:00:00 +0800

一个观察

之前在 [[../L../Library/Python_Lib/playwright/index.md]] 里写过 Playwright 自己起隔离浏览器的常规打法。但在看到一些 RPA 工具的形态后，问题就变成另一个：

为什么有些 RPA 工具是装成 Chrome 扩展，一打开就能直接「操控」用户已经登录好的页面？

答案并不复杂：这两种工具在底层就是两套完全不同的思路。

核心原理：谁拥有那个浏览器

普通 Playwright(或者类似 Puppeteer、Selenium)启动的是全新的、独立的浏览器实例，和你日常用的 Chrome 没有任何关系。Cookies 是空的，需要重新登录或注入 storage_state。

而 Chrome 扩展型 RPA 长这样：

┌──────────────────────────────────────────┐
│ 你的 Chrome 浏览器（同进程） │
│ │
│ ┌────────────┐ ┌────────────────────┐ │
│ │ Tab: 微博 │ │ Extension: RPA 工具 │ │
│ │ (已登录) │ │ 注入 content script │ │
│ └────────────┘ └────────────────────┘ │
│ ↑ │ │
│ └────────────────┘ │
│ 共享同一个 cookie 存储 │
│ 共享同一个 origin 权限 │
└──────────────────────────────────────────┘

扩展里跑的内容脚本 (content script) 语法上是独立脚本，但它直接被注入到登录页面的 DOM 里，运行在该页面的 JS context 中。所以当它调用 fetch('/api/user/info') 时，浏览器自动带上微博的 cookies，服务器认为这就是用户本人。

整件事可以浓缩成一句话：

扩展是装在你浏览器里的代码，你在浏览器里登录了什么，它就拥有什么。

这也是为什么做需要登录态的 RPA 任务，扩展方案往往比 Playwright 简单十倍 —— 因为它根本不需要解决「登录」这个问题。

几块关键拼图

扩展形式看起来神秘，其实就是下面这几块常规 MV3 API 拼起来的：

manifest.json 声明权限：

{
 "permissions": [
 "cookies",
 "storage",
 "tabs",
 "scripting",
 "activeTab"
 ],
 "host_permissions": [
 "*://*.weibo.com/*",
 "*://*.example.com/*"
 ]
}

content.js 注入目标页面，所有 fetch 自动带登录态：

async function autoPost(content) {
 document.querySelector('#editor').value = content;
 document.querySelector('#submit').click();
}

chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
 if (msg.cmd === 'post') {
 autoPost(msg.text);
 sendResponse({ ok: true });
 }
});

后台脚本 background.js 里直接读 cookie：

chrome.cookies.getAll({ domain: '.weibo.com' }, (cookies) => {
 console.log(cookies); // 直接拿到用户的所有登录态
});

把上面三块加一个 popup.html，就是最简版「扩展式 RPA」。

两种方案对比

维度	Playwright / 独立 RPA	扩展式 RPA
启动方式	独立进程，自己的浏览器	跑在用户已有的 Chrome
登录态	无，需要自登录或注入 `storage_state`	天然继承用户浏览器的登录态
反爬检测	高（指纹、IP、行为模式）	低（就是用户本人）
用户授权	无感（代码里随便用）	需要用户主动装扩展
部署难度	简单，纯代码	需要打包扩展、上架商店或 crx 安装
资源占用	完整浏览器进程	几乎为零
适用场景	批量任务、服务器端	辅助个人用户、低频任务

反爬角度的思考

扩展式 RPA 看起来「开挂」，但也不是万能：

指纹检测：window.chrome.runtime 等扩展特征可以被检测
行为检测：点击速度、操作序列如果太机械，仍能被识别
数据回流：云端 SaaS 形态的 RPA 在网络层会被分析
扩展权限：Chrome 在安装时展示权限，敏感权限可能让用户警觉
Manifest V3 限制：MV3 收紧了远程代码执行、跨域请求，扩展型 RPA 的能力被削弱

商业产品参考

UI.Vision (Kantu)：经典老牌，扩展形式，直接读用户登录态
Browserflow：Chrome 商店里很常见
Axiom.ai：扩展 + 云端
影刀 / 八爪鱼：部分功能走扩展模式，处理需要登录的网站
Automa（开源）：GitHub 上有源码，可以学到完整的实现

用 Playwright 模拟扩展式 RPA

虽然「真扩展」的形态在 Playwright 这边不好复刻（Playwright 是独立进程，无法直接读取用户 Chrome 的 cookies），但有一种折中方案：让 Playwright 复用用户已登录的浏览器。技术上叫 Persistent Context。

核心 API 是 launch_persistent_context：

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
 # 关键：指向真实 Chrome 的用户数据目录
 # macOS : ~/Library/Application Support/Google/Chrome
 # Windows: %LOCALAPPDATA%\Google\Chrome\User Data
 context = p.chromium.launch_persistent_context(
 user_data_dir='/Users/zata/Library/Application Support/Google/Chrome',
 channel='chrome', # 强制用系统 Chrome，不是 chromium
 headless=False, # 必须可视化（见下面）
 no_viewport=True,
 args=[
 '--disable-blink-features=AutomationControlled',
 '--no-first-run',
 ],
 )
 page = context.new_page()
 page.goto('https://weibo.com')
 # 此时你已经是登录状态了，直接用
 page.locator('.follow-btn').first.click()

但这条路的坑很大

和同仓库那篇 [[../L../Library/Python_Lib/playwright/index.md]] 的警告一致 —— 复用真实 Chrome 的 Profile 风险极高：

必须先完全关闭 Chrome：用户数据目录是文件锁定的，Chrome 在开的时候 Playwright 启动会直接报 Failed to create a ProcessSingleton for your profile。
headless=False 是硬需求：不是「看得到」这么简单的诉求，而是 headless 模式下被检测概率会显著上升，自动化特征也更明显。
User Data 目录要用整个 User Data，而不是 Default。
不要做 rm -rf 这种清理动作：容易连带覆盖或损坏历史、书签。

写个辅助函数降低出错的可能：

import subprocess
import time

def kill_chrome():
 """杀进程,确保数据目录不被 Chrome 自己锁住"""
 subprocess.run(['pkill', '-9', 'Google Chrome'], check=False)
 time.sleep(2)

实际可运行的完整脚本

# rpa.py
import subprocess
import time
from pathlib import Path

from playwright.sync_api import sync_playwright


CHROME_PATH = '/Applications/Google Chrome.app/Contents/MacOS/Google Chrome'
USER_DATA = Path.home() / 'Library/Application Support/Google/Chrome'


def ensure_chrome_closed() -> None:
 subprocess.run(['pkill', '-9', '-f', 'Google Chrome'], check=False)
 time.sleep(2)


def run() -> None:
 ensure_chrome_closed()

 with sync_playwright() as p:
 # Playwright 启动一个临时 Chrome 进程,加载你的用户数据
 browser = p.chromium.launch_persistent_context(
 user_data_dir=str(USER_DATA),
 executable_path=CHROME_PATH,
 headless=False,
 no_viewport=True,
 args=['--disable-blink-features=AutomationControlled'],
 ignore_default_args=['--enable-automation'],
 )

 try:
 page = browser.pages[0] if browser.pages else browser.new_page()
 page.goto('https://weibo.com')

 # 验证:这里应该能直接看到登录态
 assert '登录' not in page.title(), '用户态异常,可能 Chrome 未正常启动'

 # 开始自动化...
 page.goto('https://weibo.com/u/1234567890')
 page.locator('text=关注').first.click()
 print('✅ 关注成功')

 finally:
 browser.close()
 time.sleep(1)


if __name__ == '__main__':
 run()

进阶：CDP 远程连接

launch_persistent_context 有一个尴尬的体验：用户在自己用 Chrome，你想跑 RPA，必须先杀 Chrome 再启动一次。更优雅的方案是 Chrome DevTools Protocol（CDP）远程连接：

# 第一步：用户在终端手动启动 Chrome（带远程调试）
google-chrome --remote-debugging-port=9222

from playwright.sync_api import sync_playwright

with sync_playwright() as p:
 # 第二步：Playwright 接管这个 Chrome,而不是新启
 browser = p.chromium.connect_over_cdp('http://localhost:9222')
 context = browser.contexts[0] # 复用用户的 context
 page = context.pages[0] # 接管用户当前的 tab
 page.goto('https://weibo.com')

CDP 方案的好处：

不需要杀 Chrome
用户当前打开的 tab 可以直接被我们接管
跑完可以「无缝」还给用户

Playwright + Chrome Extension

如果目标是让用户装一个扩展，由扩展来驱动云端 Playwright，逻辑反过来：

┌─────────────────────────────────────────┐
│ 用户 Chrome │
│ ├── 你的 Extension (MV3) │
│ │ └── WebSocket 客户端 │
│ └── 普通网页 │
│ └── 被扩展的 content script 操控 │
└────────────┬────────────────────────────┘
 │ ws://localhost:8765
 ▼
┌─────────────────────────────────────────┐
│ 你的 Python 服务 │
│ ├── WebSocket Server │
│ └── Playwright(可选,云端兜底) │
└─────────────────────────────────────────┘

这种架构适合做 SaaS 化的 RPA：扩展做「采集 + 可视化」，云端 Playwright 做「批量执行」。

方案选型表

场景	推荐方案
个人脚本，偶尔跑一下	`launch_persistent_context` + 杀 Chrome
个人脚本，经常跑	CDP 远程连接 + 一个一键启动 Chrome 的 `.command` 文件
工具化，要给同事用	CDP 方案 + 配启动器
做产品，要分发	写 Chrome 扩展（完全独立，无需 Playwright）

前三种方案都没跳出 Playwright 的能力范围，基本能覆盖 90% 的需求。最后一种是真正的「扩展式 RPA」，但投入就大很多了 —— 它本身就是一个独立的产品形态，从 manifest、签名、商店审核到 MV3 限制都是另一套工程。

如果是从零开始想把 RPA 能力给到个人用户，先从 CDP 方案做起，把脚本跑通、把页面录制做成、把回放做成；等到扩展的能力真的有必要了，再考虑写 MV3 分发。

参考资料

Playwright: launch_persistent_context
Playwright: Connect over CDP
Chrome Extensions: Manifest V3 Migration
Chrome Extensions: Cookies API
rrweb / rrweb-player（会话录制的开源参考实现）
Automa - Chrome 扩展式 RPA 开源实现

浏览器会话录制与接口回放：方案调研

Mon, 27 Jul 2026 00:00:00 +0000

背景与目标

想做这样一个工具：

用户打开一个目标网站
在浏览器里手动操作（点击、输入、滚动、跳转）
后台实时记录每一步 DOM 事件 + 每个 HTTP 接口的请求/响应
操作结束后，能看到一份按时间线排列的"操作 + 接口"清单，必要时还能重放

这类能力在业内通常叫 Session Replay / 用户会话录制。

核心原理

┌─────────────┐ 事件 / 网络上报 ┌──────────┐
│ 浏览器注入 │ ────────────────────> │ 后端 │
│ SDK / 扩展 │ │ 落库 │
└─────────────┘ └──────────┘
 │ │
 │ DOM 快照 + 事件流 ▼
 └─────────────────────> 回放页面
 (rrweb-player 等)

关键三件事：

DOM 事件捕获：click / input / scroll / navigation，通常用 addEventListener 全局委托 + 事件冒泡
网络拦截：浏览器侧 XMLHttpRequest / fetch 包装一层钩子，或者用 Service Worker / 浏览器扩展的 webRequest API
DOM 变化记录：MutationObserver 监听 DOM 增量变化，配合初始快照实现像素级回放

现有方案

商业产品（开箱即用）

工具	特点
SessionStack	像素级回放 + 错误捕获 + 性能分析，企业级
FullStory	数字体验分析，强在漏斗和搜索
LogRocket	类 SessionStack，回放 + Redux/Zustand 状态回放
Hotjar	更偏热力图和漏斗
Microsoft Clarity	免费，基础回放 + 热力图

开源方案

rrweb — 最主流的开源前端录制库，用 MutationObserver + 事件监听完整还原 DOM 变化，配套有 rrweb-player 回放器。LogRocket 早期也借鉴过类似思路
rrweb-snapshot / rrweb-player — 序列化和回放子包
Playwright Trace Viewer / Patchright — 如果场景是"复现自动化流程"，Playwright 自带的 trace 就能记录每一步点击、请求、截图

自己从零做的思路

最简 MVP

浏览器扩展
 └─ content script 注入目标页面
 ├─ 监听 click / input / scroll
 ├─ 包装 XHR / fetch
 └─ 周期性上报到 /collect
后端
 └─ POST /collect → 追加写入 events.jsonl
本地 CLI
 └─ 解析 events.jsonl → 打印时间线 / 启动 rrweb-player

代码量很小，半天能跑通。

进阶版（像素级回放）

// 浏览器侧：rrweb 录制
import { record } from 'rrweb';
const events = [];
record({
 emit(event) { events.push(event); },
});
// 周期性批量上报到后端
setInterval(() => postEvents(events.splice(0)), 1000);

// 回放侧
import rrwebPlayer from 'rrweb-player';
new rrwebPlayer({
 target: document.body,
 props: { events: fetchedEvents },
});

选型建议

按"想做什么"分场景推荐：

需求	推荐方案
自己排查自动化 bug	Playwright Trace（`context.tracing.start()`），零成本
给自家产品做用户行为分析	rrweb + 自建后端，可控、私有化部署友好
想要现成的商业级方案	LogRocket / SessionStack
只想看热力图	Hotjar / Microsoft Clarity（免费）

与现有 patchright 项目的结合点

本仓库（kimi-patchright）本身在做浏览器自动化相关的 slide 调试。如果只是想在调试 slide 自动化流程时复盘浏览器里的真实操作 + 接口调用，Playwright Trace + patchright 的 page.on('request') / page.on('response') 就够用了，不需要单独再搭一套录制系统。

如果目标是 toC 的通用录制工具，那需要再想清楚定位：是要 rrweb 那种像素回放，还是只做事件流（轻量、可被搜索聚合）。

参考资料

rrweb: https://github.com/rrweb-io/rrweb
SessionStack 原理: https://www.sessionstack.com/
Playwright Trace: https://playwright.dev/docs/trace-viewer

AI 生成前端的 E2E 实践：用 Playwright 做视觉回归和功能兜底

Thu, 25 Jun 2026 14:00:00 +0800

这是「AI 时代的前端设计与实现」系列的一篇补充。前面我们聊了角色、设计系统、rules 模板和 Figma MCP；这一篇聚焦工程化落地里最常被低估的环节——端到端测试。

为什么 AI 生成的前端特别需要 E2E

AI 写前端的速度很快，但它有两个天然短板：

没有全局视角：改 A 页面时很容易把 B 页面的样式或交互带崩。
对边界状态不敏感：loading、error、empty、无权限这些状态经常被忽略。

更麻烦的是，AI 生成的代码往往看起来没问题，一跑就报错。TypeScript 和 ESLint 能拦住类型和语法错误，但拦不住这些问题：

按钮点了没反应
表单提交后没跳转
某个弹窗在特定分辨率下错位
改完配色后整个页面气质变了

E2E 测试就是针对这些问题的最后一道防线。它不只是测功能，还能帮你做视觉验收和回归防护。

E2E 要测什么

不要试图把所有东西都用 E2E 测。抓住三类高价值场景：

1. 核心用户流程（Happy Path）

用户最常用的路径必须稳定。例如电商站的「搜索 → 加购 → 结算 → 支付」。

import { test, expect } from '@playwright/test';

test('用户完成购买流程', async ({ page }) => {
 await page.goto('/products');
 await page.click('[data-testid="product-card"]:first-child');
 await page.click('[data-testid="add-to-cart"]');
 await page.click('[data-testid="checkout-button"]');
 await page.fill('[name="email"]', 'user@example.com');
 await page.click('[data-testid="submit-order"]');
 await expect(page.locator('text=订单已创建')).toBeVisible();
});

2. 错误和边界状态

AI 最容易漏的恰恰是这些：

网络失败时的 fallback UI
搜索无结果
表单校验失败
未登录访问需要权限的页面

test('搜索无结果展示空状态', async ({ page }) => {
 await page.goto('/search');
 await page.fill('[name="q"]', 'xyznotfound123');
 await page.press('[name="q"]', 'Enter');
 await expect(page.locator('[data-testid="empty-state"]')).toBeVisible();
 await expect(page.locator('text=没有找到相关结果')).toBeVisible();
});

3. 视觉回归

这是 AI 前端最关键的能力。每次 AI 改完代码，自动截图和基准图对比，像素级变化都能发现。

test('首页视觉回归', async ({ page }) => {
 await page.goto('/');
 await expect(page).toHaveScreenshot('homepage.png', {
 maxDiffPixels: 100,
 });
});

工具链选择

工具	适用场景	推荐度
Playwright	功能测试、截图回归、多浏览器、移动端模拟、trace 调试	⭐⭐⭐
Cypress	社区成熟，但多标签页、iframe 支持弱	⭐⭐
Selenium	老项目维护，新项目不推荐	⭐
Chromatic / Percy	专业 UI 回归 SaaS，适合组件级视觉对比	⭐⭐⭐
axe-core	无障碍扫描	⭐⭐⭐

建议： 新项目直接用 Playwright。它一个工具就能覆盖功能测试、视觉回归、响应式、多浏览器，失败时还能看 trace 回放。

Playwright 实战配置

安装

npm init playwright@latest

基础配置

// playwright.config.ts
import { defineConfig, devices } from '@playwright/test';

export default defineConfig({
 testDir: './e2e',
 fullyParallel: true,
 forbidOnly: !!process.env.CI,
 retries: process.env.CI ? 2 : 0,
 workers: process.env.CI ? 1 : undefined,
 reporter: [['html'], ['list']],
 use: {
 baseURL: 'http://localhost:3000',
 trace: 'on-first-retry',
 screenshot: 'only-on-failure',
 video: 'retain-on-failure',
 },
 projects: [
 { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
 { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
 { name: 'webkit', use: { ...devices['Desktop Safari'] } },
 {
 name: 'Mobile Chrome',
 use: { ...devices['Pixel 5'] },
 },
 {
 name: 'Mobile Safari',
 use: { ...devices['iPhone 12'] },
 },
 ],
 webServer: {
 command: 'npm run dev',
 url: 'http://localhost:3000',
 reuseExistingServer: !process.env.CI,
 },
});

关键配置解读：

trace: 'on-first-retry'：失败时保留 trace，可以逐帧回放。
screenshot: 'only-on-failure'：失败自动截图。
retries: 2：CI 里重试 2 次，排除 flaky。
webServer：自动起本地服务。

视觉回归怎么做

基础截图对比

test('登录页视觉回归', async ({ page }) => {
 await page.goto('/login');
 await page.waitForSelector('[data-testid="login-form"]');
 await expect(page).toHaveScreenshot('login-page.png', {
 maxDiffPixels: 100,
 threshold: 0.2,
 });
});

组件级视觉回归

如果你想测某个组件在不同状态下的样子：

test('按钮各状态截图', async ({ page }) => {
 await page.goto('/button-demos');

 await page.click('[data-testid="hover-trigger"]');
 await expect(page.locator('[data-testid="button-primary"]')).toHaveScreenshot('button-hover.png');

 await page.click('[data-testid="focus-trigger"]');
 await expect(page.locator('[data-testid="button-primary"]')).toHaveScreenshot('button-focus.png');

 await page.click('[data-testid="loading-trigger"]');
 await expect(page.locator('[data-testid="button-primary"]')).toHaveScreenshot('button-loading.png');
});

让视觉回归更稳定

视觉回归最怕 flaky。几个工程化技巧：

固定字体加载：截图前确保字体已加载。

await page.waitForFunction(() => document.fonts.ready);

屏蔽动态内容：时间、随机数、动画元素用 CSS 隐藏或 mock。

await page.addStyleTag({ content: '[data-testid="current-time"] { visibility: hidden !important; }' });

统一 viewport 和缩放：在 playwright.config.ts 里统一设备配置。

动画禁用：

await page.addStyleTag({ content: '*, *::before, *::after { animation-duration: 0s !important; transition-duration: 0s !important; }' });

响应式测试

AI 生成的页面常常在桌面端好看，移动端就崩。Playwright 可以很方便地多分辨率截图：

test.describe('响应式首页', () => {
 test.use({ viewport: { width: 375, height: 667 } });
 test('移动端', async ({ page }) => {
 await page.goto('/');
 await expect(page).toHaveScreenshot('homepage-mobile.png');
 });
});

test.describe('响应式首页桌面端', () => {
 test.use({ viewport: { width: 1440, height: 900 } });
 test('桌面端', async ({ page }) => {
 await page.goto('/');
 await expect(page).toHaveScreenshot('homepage-desktop.png');
 });
});

无障碍测试

AI 生成的代码容易忽略 alt、aria-label、对比度等。用 axe-core 跑一遍：

import { test, expect } from '@playwright/test';
import AxeBuilder from '@axe-core/playwright';

test('首页无严重无障碍问题', async ({ page }) => {
 await page.goto('/');
 const results = await new AxeBuilder({ page })
 .withTags(['wcag2a', 'wcag2aa'])
 .analyze();
 expect(results.violations).toEqual([]);
});

让 AI 参与测试工作流

E2E 不只是写测试，还可以让 AI 帮你生成和维护测试。

1. 从用户故事生成测试

把 PRD 或用户故事喂给 AI：

用户搜索商品，选择第一个结果加入购物车，进入结算页填写邮箱，提交订单后看到成功提示。

AI 输出 Playwright 测试代码，你只需微调选择器。

2. 从 Bug 报告生成回归测试

遇到一个 bug 后，先让 AI 写一个能复现它的 E2E 测试。修完 bug 再跑这个测试，确保不会回归。

3. 自动分析失败原因

Playwright 失败时会生成 trace。你可以把 trace 截图或错误日志丢给 AI，让它给出修复建议，比如：

某个选择器不稳定，建议加 data-testid
页面还没加载完，建议加 waitForSelector
某个 API 响应慢，建议 mock

4. AI 视觉验收闭环

结合 Chrome MCP / Playwright，可以建立这样的 workflow：

AI 生成代码
 ↓
Playwright 跑 E2E + 截图
 ↓
AI 对比截图 vs Figma 设计稿
 ↓
AI 提出样式修复建议
 ↓
AI 再次生成代码
 ↓
重新跑 E2E

这个闭环能大幅减少人工 Design QA 的工作量。

CI/CD 集成

在 GitHub Actions 里跑：

name: E2E Tests

on:
 pull_request:
 branches: [main]

jobs:
 e2e:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4

 - uses: actions/setup-node@v4
 with:
 node-version: 20
 cache: 'npm'

 - run: npm ci
 - run: npx playwright install --with-deps
 - run: npx playwright test

 - name: Upload Playwright report
 if: failure()
 uses: actions/upload-artifact@v4
 with:
 name: playwright-report
 path: |
 playwright-report/
 test-results/

视觉回归基准图管理

视觉回归最怕 baseline 不同步。建议：

本地开发改 UI 时，跑 npx playwright test --update-snapshots 更新自己负责的快照。
PR 里如果改了 UI，必须在 PR 描述里说明更新了哪些截图。
CI 里不允许自动更新快照，防止 silently 通过视觉回归。

给 AI 的 Rules 建议

把 E2E 要求写进 .cursorrules 或 .cursor/rules/*.mdc：

## E2E 规范

- 新增页面或核心交互后，必须在 `e2e/specs/` 下补充对应测试
- 优先使用 Playwright 和 `data-testid` 选择器，避免依赖 CSS 类名
- 每个核心流程测试必须覆盖：正常流程、空状态、错误状态
- 视觉改动必须更新 Playwright baseline 截图
- 提交前运行 `npm run test:e2e`，确保通过
- 不要写死等待时间，优先用 `waitForSelector` / `toBeVisible` 等断言

总结

E2E 测试对 AI 生成的前端有三层价值：

功能兜底：核心流程不崩溃、边界状态有处理。
视觉验收：每次改动自动截图对比，防止 UI 漂移。
回归保险：后续 AI 迭代时，不会把已有的功能改坏。

它和 design token、组件库、TypeScript、rules 组合起来，才能把「AI 生成前端」从 demo 变成可维护、可上线的产品。

参考

从 noVNC 到 Playwright 截图流：容器内 VNC 踩坑记

Tue, 09 Jun 2026 14:00:00 +0800

背景

项目是一个 FastAPI 后端 + Playwright 驱动的浏览器自动化服务，目标是让用户在网页里远程操作一个跑在 Docker 容器内的 Chrome，完成 kimi.com 的一次性扫码/账号登录。登录态写入持久化 profile，后续 PPT 生成任务复用。

远程桌面的需求看起来很简单：

容器内：Xvfb（虚拟显示）+ openbox（窗口管理）+ x11vnc（VNC 服务端）
后端：FastAPI WebSocket 做字节中继，把前端的 RFB 流量转发到 127.0.0.1:5910
前端：@novnc/novnc 的 RFB 类连接 WebSocket，渲染桌面

架构上也很规矩：5910 不对外暴露，WebSocket 走 443/HTTPS，用管理员 token + 一次性 ticket 鉴权，没有旁路端口。

PRD 写得整整齐齐，验收清单全部打勾，看起来万无一失。然后我们就掉进了坑里。

坑一：MIT-SHM 0-byte 画面

症状：noVNC 连接成功，但画面全黑，或者显示 0-byte 的帧。

根因：x11vnc 默认使用 X11 的 MIT-SHM（共享内存扩展）加速画面抓取。在 Docker 容器里，共享内存行为跟宿主机不一致，x11vnc 读不到像素数据。

修复（2fa2602）：给 x11vnc 加参数绕过 MIT-SHM：

x11vnc -noxshm -noxkb -noxrecord -noxfixes -noxdamage ...

或者通过环境变量透传：

X11VNC_EXTRA_ARGS="-noxshm -ncache 0"

这个坑还算好填，加参数就能绕过。

坑二：Chrome VizDisplayCompositor 导致黑屏

症状：x11vnc 终于有画面了，但 Chrome 窗口区域永远是黑的。其他窗口（xterm、openbox）显示正常。

根因：Chrome 默认启用 Viz Display Compositor，把实际渲染放到独立的合成器进程里，用 GPU 或特殊缓冲区，导致普通的 X11 像素读取（XGetImage、XShmGetImage）抓不到 Chrome 内容。

修复（58cb8ed）：启动 Chrome 时禁用 VizDisplayCompositor：

google-chrome --disable-features=VizDisplayCompositor ...

这个坑比较隐蔽，因为其他应用都能正常显示，唯独 Chrome 黑屏。排查了好一阵才定位到是 Chrome 的合成器机制。

坑三：x11vnc 在 Azure VM 上的兼容性

症状：本地 Mac Docker Desktop 测试正常，推到 Azure VM（Ubuntu 24.04，内核 6.14.0-1017-azure）后，x11vnc 要么崩溃，要么帧率极低，要么随机断开。

根因：x11vnc 对内核版本、X11 扩展、共享内存的依赖比较深，不同宿主机环境表现差异很大。

这时候我们开始尝试替换 VNC 服务端。

尝试 1：x0vncserver

TigerVNC 的 x0vncserver 更轻量，但 Ubuntu 24.04 的软件源里根本没有这个包（6765172）。

尝试 2：Xtigervnc

切换到 Xtigervnc（1d3222c），但发现它的 X0 扩展支持不完整，抓取现有 X 会话的能力不如 x11vnc。

尝试 3：x11vnc + ncache

最后又滚回 x11vnc，加上 -ncache 10 做客户端缓存（8ba411d），试图缓解帧率问题。

这一系列反复说明一个问题：在容器化 + 云服务器环境下跑传统 VNC 服务端，是一件非常脆弱的事。每个环境变量、每个内核版本、每个 X11 扩展都可能成为压垮骆驼的最后一根稻草。

最终方案：彻底放弃 VNC，改用 Playwright 截图

与其继续跟 x11vnc 搏斗，我们换了一个思路：

既然 Playwright 已经开着 Chrome，为什么不直接让 Playwright 截屏？

新方案（40b9014）：

后端：Playwright 的 Page.screenshot() 每 250ms 截一张图
传输：自定义 WebSocketFrameBridge，把 PNG 字节包上 length-prefixed JSON envelope，通过现有 WebSocket 推给前端
前端：不用 noVNC RFB 了，直接用原生 WebSocket 收帧，把 PNG blob 塞进 <img> 标签
输入：前端把鼠标/键盘事件序列化成 JSON，通过同一个 WebSocket 发回后端，后端用 page.mouse.click()、page.keyboard.press() 回放

Wire 格式：

4-byte LE length (uint32)
N bytes JSON: {"type": "frame", "seq": N, "size": M, "format": "jpeg"}
4-byte LE length (uint32)
M bytes PNG payload

新旧方案对比

维度	noVNC + x11vnc	Playwright 截图流
依赖	Xvfb + openbox + x11vnc + MIT-SHM workaround	只有 Xvfb
Chrome 兼容性	需要 `--disable-features=VizDisplayCompositor`	不需要特殊 flags
容器稳定性	极易受宿主机内核/环境差异影响	纯用户态，跟宿主机无关
带宽	RFB 协议有增量压缩，带宽低	每帧完整 PNG/JPEG，带宽高
延迟	RFB 增量更新，延迟低	250ms 轮询，延迟稍高
实现复杂度	需要 RFB 中继、VNC 参数调优	自定义帧协议，前后端约 200 行
可维护性	x11vnc 是黑盒，出问题难排查	Playwright 截图是白盒，可控

牺牲了一点带宽和延迟，换来的是极高的稳定性和可维护性。

教训

VNC 协议是为局域网桌面共享设计的，强行塞进 Docker + 浏览器自动化的场景，属于削足适履。MIT-SHM、GPU 合成器、X11 扩展这些历史包袱在容器里会集中爆发。
当你在同一个组件上打了 3 个以上补丁还搞不定时，应该考虑替换它。我们在 x11vnc 上修了 MIT-SHM、VizDisplayCompositor、ncache、环境参数透传……最后发现换掉它比修好它更容易。
用你已经有的工具链解决问题。既然 Playwright 已经开着浏览器，截屏是它的一等公民 API，为什么不直接用？不要为了追求"标准方案"而引入一整套 VNC 技术栈。
“网页远程桌面"不等于"必须实现 VNC/RDP 协议”。只要用户能看到画面、能发鼠标键盘，用什么协议不重要。自定义的 JSON+PNG 帧流完全够用。

代码速查

如果你也在用 Playwright + Docker + 远程桌面，可以直接参考这个模式。

后端截屏（Python）：

async def next_frame(self) -> bytes:
 return await page.screenshot(
 type="jpeg",
 quality=70,
 full_page=False,
 )

前端渲染（TypeScript/React）：

const ws = new WebSocket(url);
ws.binaryType = "arraybuffer";
ws.onmessage = (event) => {
 const blob = new Blob([event.data], { type: "image/jpeg" });
 setFrameUrl(URL.createObjectURL(blob));
};

后端输入回放（Python）：

async def dispatch(self, event: dict) -> None:
 if event["type"] == "click":
 await page.mouse.click(event["x"], event["y"])
 elif event["type"] == "keydown":
 await page.keyboard.press(event["key"])

Playwright Chromium 在 Docker 内 SIGTRAP 启动崩溃排查实录

Mon, 08 Jun 2026 15:30:00 +0800

背景

一个 FastAPI 后端 + Playwright（驱动 Chromium 做爬虫/自动化）的项目，通过 Dokploy 部署到一台 Azure VM（内核 6.14.0-1017-azure，Ubuntu 24.04）。前端点登录按钮，后端通过 launch_persistent_context 起 Chromium 让用户走 VNC 完成一次性登录。

部署后第一次点登录就报：

TargetClosedError: BrowserType.launch_persistent_context:
Target page, context or browser has been closed
<launched> pid=191
[pid=191][err] chrome_crashpad_handler: --database is required
[pid=191][err] [191:191:...:ERROR:.../socket.cc:120] recvmsg: Connection reset by peer (104)
[pid=191] <process did exit: exitCode=null, signal=SIGTRAP>

chrome_crashpad_handler: --database is required 看起来像主角，其实只是遗书：父 chrome 进程已经 SIGTRAP，crashpad handler 被附带拉起来时没拿到参数，才吐了 usage。先理清这一点才不会被带偏。

下面把六轮被自己打脸的错误假设逐一列出，再讲真正根因。值得保留的不是答案，是思路。

假设 1：旧 profile 跨版本残留

docker-compose 把 kimi-ppt-browser-profile 命名卷挂到 /app/.courier/browser-profiles。第一反应：上次构建的 Chromium 写下的 profile 文件和这次不兼容，启动 assert。

结果：用户说"全新部署，没操作过任何东西"。卷是 fresh 的，假设不成立。

假设 2：Docker 默认 seccomp 拦 `clone3`

Chromium 1223 (Playwright ≥ 1.49 bundled) 大量用 clone3。老 Docker daemon（≤ 20.10.10）的默认 seccomp profile 直接 EPERM。

修了一行 compose：

 kimi-ppt-backend:
 security_opt:
 - seccomp=unconfined

结果：重新部署 → 同样的 SIGTRAP。排除。

假设 3：换系统 Google Chrome stable

既然 bundled chromium 1322 跑不起来，换 Google 官方 deb 装的 google-chrome-stable 总行了吧？把 Dockerfile 改成从 Google APT 装，KIMI_SLIDES_BROWSER_CHANNEL=chrome 让 Playwright 通过 channel='chrome' 调它。

结果：chrome 一样 SIGTRAP。说明不是 chromium binary 自身的 bug。

假设 4：AppArmor 拦 userns

写了一个分层探针脚本进入容器实际查原因。关键输出：

[1] docker inspect
 AppArmorProfile: docker-default
 SecurityOpt: [seccomp=unconfined]
[2] kernel sysctls
 apparmor_restrict_unprivileged_userns = 1
[4] strace of chrome stable
 chrome 主 (pid 353) sendmsg(fd4, 40 bytes) → 给 crashpad handler 发 IPC 配置
 crashpad handler (pid 355) execve(...)
 crashpad handler +++ exited with 1 +++
 chrome 主 --- SIGTRAP si_code=SI_KERNEL ← IMMEDIATE_CRASH(int3)

apparmor_restrict_unprivileged_userns=1 配合 docker-default profile 会让 chrome 创建 user namespace 失败。给 compose 加：

 kimi-ppt-backend:
 security_opt:
 - seccomp=unconfined
 - apparmor=unconfined

结果：AppArmor 是 unconfined 了，chrome 仍然 SIGTRAP。strace 显示 crashpad handler 启动后没拿到 --database= 参数就退（更详尽的 strace 揭示真正原因——见下），所以 userns 不是真正卡点。这是被自己打脸的一轮：加 apparmor=unconfined 之后我又跑了一次 strace，发现 crashpad handler 根本没走到 userns 那一步，它在解析 argv 阶段就 fail 了。

留这一段不是为了丢脸——是因为这次"加了一行还是没好"教会我：每加一行配置就重新跑一次 strace 看新输出，不能凭印象假设前一次 trace 仍然成立。

真正根因：HOME 目录不存在

回头看 [4] 那段 strace：

355 (handler) execve args = [...--initial-client-fd=5 --shared-client-connection]
 ↑ 注意：没有 --database=
355 write(stderr, "chrome_crashpad_handler: --datab...")
355 +++ exited with 1 +++

chrome 主进程传给 crashpad handler 的 argv 里没有 --database=。为什么？因为 chrome 决定 --database= 路径的算法是 ~/.config/google-chrome/Crash Reports，根据 $HOME 推。

继续探针：

[2] HOME 探测
 HOME=/home/appuser
 ls -ld /home/appuser → No such file or directory

[3] 同样的 chrome 命令用 root 跑
 <html><head></head><body></body></html> ← 正常！

Dockerfile 里有一行：

RUN groupadd -r appgroup && useradd -r -g appgroup appuser

useradd -r 创建系统用户，默认不创 home 目录。appuser 进了 /etc/passwd 但 /home/appuser 不存在。chrome 拿不到可写 $HOME → 不传 --database= 给 crashpad handler → handler exit 1 → chrome 主进程检测到 handler init 失败 → IMMEDIATE_CRASH() 调 __builtin_debugtrap() → SIGTRAP。

root 能跑是因为 HOME=/root，目录存在。

修复（一行 Dockerfile）：

RUN groupadd -r appgroup && useradd -r -g appgroup -m -d /home/appuser appuser \
 && mkdir -p /app/logs /app/downloads /app/.courier/browser-profiles \
 && chown -R appuser:appgroup /app /home/appuser

useradd -m -d /home/appuser 才会真创建 home 目录。

Dokploy Redeploy（重新 build 镜像，3-5 分钟，不是 9 秒的 hot restart）后，chrome 启动正常。

顺手修了一个 selector bug

chrome 起来后，前端点登录立刻弹"已检测到登录成功"——其实没登录。查代码发现 sites/kimi-slides.yaml:11 配的是 logged_in_selector: ".chat-input-editor"，而 kimi.com 的未登录落地页就有 .chat-input-editor，selector 立即命中，on_login_detected 被错误 fire。

从 VNC 里看登录后页面才出现的元素：

<div class="user-avatar-container" style="width: 28px; height: 28px;">
 <img class="user-avatar" src="...music_head.png" alt="登月者9246" />
 <span class="user-name">登月者9246</span>
 <div class="membership-upgrade">升级</div>
</div>

membership-upgrade（“升级"按钮）和 .user-avatar-container 都是只在登录后才出现的——是更可靠的 post-auth marker。把 selector 换成 .user-avatar-container 即可。

5 条复盘

1. `chrome_crashpad_handler: --database is required` 是结果不是原因

每次看到这一行都要立刻去找父 chrome 进程的退出信号。SIGTRAP / trap int3 几乎一定是 Chromium 内部 IMMEDIATE_CRASH()。crashpad 那段 usage 是它被附带拉起来时打出来的"遗言”，跟死因无关。

2. 剥变量比改 compose 重要

报错涉及：卷 / 权限 / seccomp / X server / GPU / 内核 / CPU 指令 / 缺库 / 容器 runtime / app config / 用户身份。每一条都可能引发同一种症状。写脚本一次性把可控变量全部剥掉（手动跑 chromium、用 /tmp 隔离卷、headless 隔离 X、--no-zygote --single-process 隔离 sandbox），比改一行 compose 重新部署等结果效率高得多。

特别有价值的一步是 strace 死前最后那个 syscall——能直接定位到 clone3 / seccomp / userfaultfd / prctl 哪一类失败。这一步把"猜容器层问题"变成"看 kernel 在哪一步拒绝"。

3. `--no-sandbox` 不等于 sandbox 完全关掉

Chromium 至少有三层 sandbox：setuid sandbox、user-namespace sandbox、seccomp-bpf filter。--no-sandbox 主要关掉前两层，仍可能在 seccomp 初始化阶段崩。要全关需要：

--no-sandbox --disable-setuid-sandbox --disable-namespace-sandbox --disable-seccomp-filter-sandbox

但这只用于诊断——生产即便有问题也不要靠这个绕。

4. bundled chromium 不是万能

Playwright 自带的 Chromium 是 Playwright 团队 patched 过的版本，覆盖矩阵窄于 Google 官方 Chrome stable。Azure / 较新 Hyper-V 内核 / 某些 ARM 宿主三者叠加就可能让 bundled chromium 启动崩、而系统 Chrome stable 正常——反过来也成立。生产容器优先用 channel='chrome' 跑系统 Chrome 更保守。

但！这次我们后来发现"换 Chrome stable"本身也不是修复——根因（HOME 缺失）对两个 binary 一视同仁。换 binary 治不了真正的病，只是让症状换了个皮。

5. Dockerfile 一行 `-m` 缺失，藏得最深

useradd -r 不创 home——这是发行版默认行为，dev 阶段本地跑的时候从来不会触发（Mac 跑 docker 不走 rootfs，mount 行为不一样），CI 测试也跑过（其实没跑过——just test 不覆盖 docker build）。这种 bug 只能靠"上 prod 看现象"暴露。

防御：

Dockerfile 优先用 adduser（Debian 系）而不是 useradd，adduser 默认创 home 且交互友好
或者显式 -m -d /home/xxx 让意图不依赖隐式默认
在 CI 里至少跑一次 docker build && docker run 验证 chrome 类应用能起，单纯跑 pytest 不够

完整最终改动

src/backend/Dockerfile：useradd 加 -m -d /home/appuser；chown 补 /home/appuser
docker-compose.dokploy.yml：security_opt: [seccomp=unconfined, apparmor=unconfined]（虽然对 chromium 启动不是必须的，但保险）
sites/kimi-slides.yaml：login_detection_selector 从 .chat-input-editor 换成 .user-avatar-container

附录：诊断脚本模式

发现 strace 末尾 “死前最后几个 syscall” 价值最高，标准化成模板：

docker exec "$CONTAINER" sh -c '
 CHROME=/opt/google/chrome/chrome
 rm -rf /tmp/cp /tmp/strace.log
 timeout 5 strace -f -y \
 -e trace=execve,clone,clone3,prctl,seccomp,unshare,ptrace,personality,\
membarrier,userfaultfd,pidfd_open \
 -o /tmp/strace.log \
 "$CHROME" --headless=new --no-sandbox --disable-dev-shm-usage --disable-gpu \
 --user-data-dir=/tmp/cp about:blank >/dev/null 2>&1
 HANDLER_PID=$(grep "execve.*chrome_crashpad_handler" /tmp/strace.log | head -1 | awk "{print \$1}")
 grep "^$HANDLER_PID " /tmp/strace.log | tail -40
'

-y 会显示 fd 对应的资源；-f 跟踪子进程；trace 列表只列我们关心的 syscall 防止输出爆炸。

任何 chromium 启动崩的现场，这套脚本是首选入口。

Playwright 使用实践与本地浏览器 Profile 避坑

Sun, 31 Aug 2025 08:13:49 +0800

一个代价很大的坑

我之前写 Playwright 程序时，希望它直接使用电脑上安装的浏览器和已有登录状态，于是让它复用了本地 Chrome 的用户目录。结果自动化运行后，日常浏览器里的历史记录全部消失了。

这个经历里最容易混淆的是两件事：

使用本机安装的 Chrome 程序：通常没问题。
使用日常 Chrome 的用户数据目录（Profile）：风险很高，不应该这样做。

Playwright 默认创建隔离的 BrowserContext，其行为类似一个全新的无痕环境，不会读取日常 Chrome 的历史记录、Cookie 或扩展。只有在使用 launch_persistent_context() 并把 user_data_dir 指向真实 Chrome 用户目录时，自动化程序才会直接读写日常浏览数据。

为什么真实 Profile 可能出问题

Chrome 的用户目录中不只是 Cookie，还包含：

History：浏览历史数据库
Cookies：Cookie 数据库
Login Data：保存的登录信息
Bookmarks：书签
Preferences：浏览器配置
扩展、缓存和站点本地存储

这些文件中有不少是 SQLite 数据库。普通 Chrome 和 Playwright 同时访问同一个 Profile，可能发生文件锁冲突、数据库损坏或配置覆盖。如果脚本还带有清理、复制、初始化目录的逻辑，就可能直接覆盖原数据。

另外，Chrome 现在也限制自动化工具访问默认用户目录。Playwright 官方明确建议：不要把日常 Chrome 的主 User Data 目录传给自动化程序，而应创建独立目录作为自动化 Profile。

错误示例：直接复用日常 Chrome Profile

macOS 上，Chrome 的用户数据通常位于：

~/Library/Application Support/Google/Chrome

不要这样写：

from pathlib import Path

from playwright.sync_api import sync_playwright


chrome_user_data_dir = (
 Path.home() / "Library/Application Support/Google/Chrome"
)

with sync_playwright() as playwright:
 context = playwright.chromium.launch_persistent_context(
 user_data_dir=chrome_user_data_dir,
 channel="chrome",
 headless=False,
 )
 page = context.new_page()
 page.goto("https://example.com")
 context.close()

这里的危险点不是 channel="chrome"，而是 user_data_dir 指向了日常使用的 Chrome 数据目录。

还要注意，chrome://version 中显示的“个人资料路径”可能是：

.../Google/Chrome/Default

而 Chromium 启动参数所需的 user_data_dir 是它的父目录：

.../Google/Chrome

不要因为两者层级不同，就尝试把 Default 或它的父目录逐个传给脚本测试；它们都属于真实浏览数据。

正确方案一：使用系统 Chrome，但创建专用 Profile

如果需要有头浏览器、持久化 Cookie 或长期登录状态，可以为自动化单独创建目录：

from pathlib import Path

from playwright.sync_api import sync_playwright


automation_profile_dir = Path.cwd() / ".playwright-profile"
automation_profile_dir.mkdir(parents=True, exist_ok=True)

with sync_playwright() as playwright:
 context = playwright.chromium.launch_persistent_context(
 user_data_dir=automation_profile_dir,
 channel="chrome",
 headless=False,
 )
 page = context.pages[0] if context.pages else context.new_page()
 page.goto("https://example.com")
 context.close()

这段代码中：

channel="chrome" 使用本机安装的 Google Chrome。
.playwright-profile 只供自动化程序使用。
关闭后 Cookie、本地存储等仍会保留，下一次运行可以继续使用。
日常 Chrome 和自动化 Chrome 的数据完全分离。

应把专用 Profile 加入 .gitignore，避免将 Cookie 或凭据提交到仓库：

.playwright-profile/

正确方案二：只保存登录状态

如果只是运行测试，通常不需要保存整个浏览器 Profile。更轻量的做法是登录一次后导出 storage_state：

from pathlib import Path

from playwright.sync_api import sync_playwright


auth_state_path = Path("playwright/.auth/user.json")
auth_state_path.parent.mkdir(parents=True, exist_ok=True)

with sync_playwright() as playwright:
 browser = playwright.chromium.launch(headless=False)
 context = browser.new_context()
 page = context.new_page()

 page.goto("https://example.com/login")
 # 在这里完成登录。

 context.storage_state(path=auth_state_path)
 browser.close()

后续运行时加载它：

from playwright.sync_api import sync_playwright


with sync_playwright() as playwright:
 browser = playwright.chromium.launch()
 context = browser.new_context(
 storage_state="playwright/.auth/user.json",
 )
 page = context.new_page()
 page.goto("https://example.com")
 browser.close()

storage_state 主要保存 Cookie、localStorage 和 IndexedDB，比复制整个 Profile 更适合自动化测试。但这个文件仍可能包含有效登录凭据，也必须加入 .gitignore：

playwright/.auth/

普通隔离模式

不需要复用登录状态时，直接使用 Playwright 默认的隔离模式最安全：

from playwright.sync_api import sync_playwright


with sync_playwright() as playwright:
 browser = playwright.chromium.launch(
 channel="chrome",
 headless=False,
 )
 context = browser.new_context()
 page = context.new_page()
 page.goto("https://example.com")
 browser.close()

每个新建的 BrowserContext 都是独立的干净环境。关闭 Context 后其中的临时 Cookie 和本地存储会被丢弃，但不会触碰日常 Chrome Profile。

安全检查清单

在运行任何复用浏览器状态的 Playwright 程序前，至少检查以下事项：

user_data_dir 是否指向专用目录，而不是 Chrome、Edge 或 Chromium 的日常用户目录。
普通浏览器和 Playwright 是否会同时打开同一个 Profile。
cleanup 逻辑是否可能对未校验的路径执行 rmtree()、rm -rf 或覆盖复制。
是否可以用 storage_state 替代整个持久化 Profile。
自动化 Profile 和认证状态文件是否已加入 .gitignore。
重要浏览器数据是否有同步或系统备份。

如果程序必须清理自动化 Profile，应使用固定的专用路径，并在删除前验证目录名称。不要对来自环境变量或外部输入、尚未解析和校验的路径直接执行递归删除。

历史记录消失后的排查

发现历史记录不见后，先不要继续频繁启动 Chrome：

完全退出普通 Chrome 和 Playwright。
备份整个 Chrome 用户目录。
打开 chrome://version，确认普通 Chrome 当前使用的是 Default、Profile 1 还是其他 Profile。
检查各 Profile 下是否仍有 History 文件。
检查 Chrome Sync、Time Machine 或其他系统备份。

macOS 上常见的历史数据库位置包括：

~/Library/Application Support/Google/Chrome/Default/History
~/Library/Application Support/Google/Chrome/Profile 1/History

History 是 SQLite 数据库。如果只是切换到了空 Profile，原数据可能仍在其他目录；如果数据库已被覆盖或重新创建，则需要从同步或备份中恢复。

总结

使用 Playwright 时要区分“浏览器程序”和“浏览器数据”：

想使用本地 Chrome：设置 channel="chrome"。
想保存自动化登录状态：使用专用 user_data_dir。
只想复用测试登录态：优先使用 storage_state。
永远不要让自动化程序直接操作日常 Chrome Profile。

Browser Automation on 扎塔-Zata

扩展式 RPA：从 Chrome 扩展原理到 Playwright 实战方案

一个观察

核心原理：谁拥有那个浏览器

几块关键拼图

两种方案对比

反爬角度的思考

商业产品参考

用 Playwright 模拟扩展式 RPA

但这条路的坑很大

实际可运行的完整脚本

进阶：CDP 远程连接

Playwright + Chrome Extension

方案选型表

参考资料

浏览器会话录制与接口回放：方案调研

背景与目标

核心原理

现有方案

商业产品（开箱即用）

开源方案

自己从零做的思路

最简 MVP

进阶版（像素级回放）

选型建议

与现有 patchright 项目的结合点

参考资料

AI 生成前端的 E2E 实践：用 Playwright 做视觉回归和功能兜底

为什么 AI 生成的前端特别需要 E2E

E2E 要测什么

1. 核心用户流程（Happy Path）

2. 错误和边界状态

3. 视觉回归

工具链选择

Playwright 实战配置

安装

基础配置

视觉回归怎么做

基础截图对比

组件级视觉回归

让视觉回归更稳定

响应式测试

无障碍测试

让 AI 参与测试工作流

1. 从用户故事生成测试

2. 从 Bug 报告生成回归测试

3. 自动分析失败原因

4. AI 视觉验收闭环

推荐的目录结构

CI/CD 集成

视觉回归基准图管理

给 AI 的 Rules 建议

总结

参考

从 noVNC 到 Playwright 截图流：容器内 VNC 踩坑记

背景

坑一：MIT-SHM 0-byte 画面

坑二：Chrome VizDisplayCompositor 导致黑屏

坑三：x11vnc 在 Azure VM 上的兼容性

尝试 1：x0vncserver

尝试 2：Xtigervnc

尝试 3：x11vnc + ncache

最终方案：彻底放弃 VNC，改用 Playwright 截图

新旧方案对比

教训

代码速查

Playwright Chromium 在 Docker 内 SIGTRAP 启动崩溃排查实录

背景

假设 1：旧 profile 跨版本残留

假设 2：Docker 默认 seccomp 拦 clone3

假设 3：换系统 Google Chrome stable

假设 4：AppArmor 拦 userns

真正根因：HOME 目录不存在

顺手修了一个 selector bug

5 条复盘

1. chrome_crashpad_handler: --database is required 是结果不是原因

2. 剥变量比改 compose 重要

3. --no-sandbox 不等于 sandbox 完全关掉

4. bundled chromium 不是万能

5. Dockerfile 一行 -m 缺失，藏得最深

假设 2：Docker 默认 seccomp 拦 `clone3`

1. `chrome_crashpad_handler: --database is required` 是结果不是原因

3. `--no-sandbox` 不等于 sandbox 完全关掉

5. Dockerfile 一行 `-m` 缺失，藏得最深