Back to Details

playwright-interactive-sandbox

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Core Workflow

核心工作流程

  1. Write a brief QA inventory before testing:
    • Build the inventory from three sources: the user's requested requirements, the user-visible features or behaviors you actually implemented, and the claims you expect to make in the final response.
    • Anything that appears in any of those three sources must map to at least one QA check before signoff.
    • List the user-visible claims you intend to sign off on.
    • List every meaningful user-facing control, mode switch, or implemented interactive behavior.
    • List the state changes or view changes each control or implemented behavior can cause.
    • Use this as the shared coverage list for both functional QA and visual QA.
    • For each claim or control-state pair, note the intended functional check, the specific state where the visual check must happen, and the evidence you expect to capture.
    • If a requirement is visually central but subjective, convert it into an observable QA check instead of leaving it implicit.
    • Add at least 2 exploratory or off-happy-path scenarios that could expose fragile behavior.
  2. Start or confirm any required dev server in a persistent TTY session.
  3. Write a dedicated Playwright verification script for the changed flow.
  4. Run the desktop script first, then add a mobile script if the change affects mobile layouts or touch behavior.
  5. After each code change, rerun the verification script from a clean Node.js process.
  6. Run functional QA with normal user input.
  7. Run a separate visual QA pass.
  8. Verify viewport fit and capture the screenshots needed to support your claims.
  9. Save screenshot artifacts from the successful run.
  1. 测试前编写简短的QA清单：
    • QA清单需从三个来源整理：用户提出的需求、实际实现的用户可见功能或行为，以及你在最终反馈中要做出的承诺。
    • 上述三个来源中出现的任何内容，在验收前都必须对应至少一项QA检查。
    • 列出你打算验收的用户可见承诺。
    • 列出所有有意义的用户端控件、模式切换或已实现的交互行为。
    • 列出每个控件或已实现行为可能引发的状态变更或视图变更。
    • 将此清单作为功能QA和视觉QA的共享覆盖列表。
    • 针对每项承诺或控件-状态组合，记录预期的功能检查、必须执行视觉检查的特定状态，以及你预期捕获的证据。
    • 如果某项需求以视觉为核心但带有主观性，将其转化为可观察的QA检查，而非留作隐含要求。
    • 至少添加2个探索性或非顺畅路径场景，以暴露潜在的脆弱行为。
  2. 在持久化TTY会话中启动或确认所需的开发服务器。
  3. 为变更后的流程编写专用的Playwright验证脚本。
  4. 先运行桌面端脚本，若变更影响移动端布局或触摸行为，再添加移动端脚本。
  5. 每次代码变更后，从干净的Node.js进程重新运行验证脚本。
  6. 使用正常用户输入执行功能QA。
  7. 执行单独的视觉QA检查。
  8. 视口适配性并捕获支撑你承诺所需的截图。
  9. 保存成功运行后的截图产物。

Desktop Verification Script

桌面端验证脚本

Set 
TARGET_URL
to the app you are debugging. Use port 
4444
and prefer 
127.0.0.1
over 
localhost
.
In this Debian sandbox, use headless mode for Playwright. Do not spend attempts trying headed mode unless the environment explicitly provides an X server.
In this Debian sandbox, use headless mode for Playwright. Do not spend attempts trying headed mode unless the environment explicitly provides an X server.
In this Debian sandbox, use headless mode for Playwright. Do not spend attempts trying headed mode unless the environment explicitly provides an X server.
javascript
import { chromium } from 'playwright';

const TARGET_URL = 'http://127.0.0.1:4444';
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({
	viewport: { width: 1600, height: 900 }
});
const page = await context.newPage();

try {
	await page.goto(TARGET_URL, { waitUntil: 'domcontentloaded' });
	console.log('Loaded:', await page.title());

	// Add the task-specific interactions and assertions here.

	await page.screenshot({ path: 'playwright-desktop.png', type: 'png' });
} finally {
	await context.close().catch(() => {});
	await browser.close().catch(() => {});
}
Use this pattern for the main changed flow. Keep the script focused on the exact behavior you need to verify.
Example check run:
bash
node /tmp/playwright-verify-desktop.mjs
将
TARGET_URL
设置为你调试的应用地址。使用端口
4444
，优先选择
127.0.0.1
而非
localhost
。
在此Debian沙箱中，使用Playwright的无头模式。除非环境明确提供X服务器，否则不要尝试使用有头模式。
在此Debian沙箱中，使用Playwright的无头模式。除非环境明确提供X服务器，否则不要尝试使用有头模式。
在此Debian沙箱中，使用Playwright的无头模式。除非环境明确提供X服务器，否则不要尝试使用有头模式。
javascript
import { chromium } from 'playwright';

const TARGET_URL = 'http://127.0.0.1:4444';
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({
\tviewport: { width: 1600, height: 900 }
});
const page = await context.newPage();

try {
\tawait page.goto(TARGET_URL, { waitUntil: 'domcontentloaded' });
\tconsole.log('Loaded:', await page.title());

\t// Add the task-specific interactions and assertions here.

\tawait page.screenshot({ path: 'playwright-desktop.png', type: 'png' });
} finally {
\tawait context.close().catch(() => {});
\tawait browser.close().catch(() => {});
}
针对主要变更流程使用此模式。保持脚本聚焦于你需要验证的具体行为。
示例检查运行：
bash
node /tmp/playwright-verify-desktop.mjs

Mobile Verification Script

移动端验证脚本

Use a separate mobile script when the task affects responsive layout or touch behavior.
javascript
import { chromium } from 'playwright';

const TARGET_URL = 'http://127.0.0.1:4444';
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({
	viewport: { width: 390, height: 844 },
	isMobile: true,
	hasTouch: true
});
const page = await context.newPage();

try {
	await page.goto(TARGET_URL, { waitUntil: 'domcontentloaded' });
	console.log('Loaded mobile:', await page.title());

	// Add the task-specific interactions and assertions here.

	await page.screenshot({ path: 'playwright-mobile.png', type: 'png' });
} finally {
	await context.close().catch(() => {});
	await browser.close().catch(() => {});
}
当任务影响响应式布局或触摸行为时，使用单独的移动端脚本。
javascript
import { chromium } from 'playwright';

const TARGET_URL = 'http://127.0.0.1:4444';
const browser = await chromium.launch({ headless: true });
const context = await browser.newContext({
\tviewport: { width: 390, height: 844 },
\tisMobile: true,
\thasTouch: true
});
const page = await context.newPage();

try {
\tawait page.goto(TARGET_URL, { waitUntil: 'domcontentloaded' });
\tconsole.log('Loaded mobile:', await page.title());

\t// Add the task-specific interactions and assertions here.

\tawait page.screenshot({ path: 'playwright-mobile.png', type: 'png' });
} finally {
\tawait context.close().catch(() => {});
\tawait browser.close().catch(() => {});
}

Iteration Model

迭代模型

  • Use one standalone Node.js script per verification pass.
  • After code changes, rerun the verification script from a clean process instead of trying to preserve state across runs.
  • Keep each script narrow: one changed flow, its main assertions, and its screenshot artifacts.
  • If desktop and mobile both matter, run separate scripts or separate invocations rather than one large stateful script.
  • 每次验证使用一个独立的Node.js脚本。
  • 代码变更后，从干净进程重新运行验证脚本，而非尝试在多次运行间保留状态。
  • 保持每个脚本的范围狭窄：仅包含一个变更流程、其主要断言以及截图产物。
  • 若桌面端和移动端都需要验证，运行单独的脚本或单独调用，而非使用一个大型有状态脚本。

Checklists

检查清单

Session Loop

会话循环

  • Write and run the Node.js Playwright verification script for the current validation run.
  • Launch the target web app from the current workspace.
  • Make the code change.
  • Reload or restart using the correct path for that change.
  • Update the shared QA inventory if exploration reveals an additional control, state, or visible claim.
  • Re-run functional QA.
  • Re-run visual QA.
  • Capture final artifacts only after the current state is the one you are evaluating.
  • 为当前验证运行编写并执行Node.js Playwright验证脚本。
  • 从当前工作区启动目标Web应用。
  • 进行代码变更。
  • 使用对应变更的正确路径重新加载或重启应用。
  • 若探索过程发现额外的控件、状态或可见承诺，更新共享QA清单。
  • 重新执行功能QA。
  • 重新执行视觉QA。
  • 仅当当前状态为你评估的状态时，捕获最终产物。

Reload Decision

重新加载决策

  • Renderer-only change: reload the existing page.
  • New uncertainty about whether the current script still matches the changed behavior: rerun a clean script instead of guessing.
  • 仅渲染层变更：重新加载现有页面。
  • 不确定当前脚本是否仍匹配变更后的行为：重新运行干净的脚本，而非猜测。

Functional QA

功能QA

  • Use real user controls for signoff: keyboard, mouse, click, touch, or equivalent Playwright input APIs.
  • Verify at least one end-to-end critical flow.
  • Confirm the visible result of that flow, not just internal state.
  • For realtime or animation-heavy apps, verify behavior under actual interaction timing.
  • Work through the shared QA inventory rather than ad hoc spot checks.
  • Cover every obvious visible control at least once before signoff, not only the main happy path.
  • For reversible controls or stateful toggles in the inventory, test the full cycle: initial state, changed state, and return to the initial state.
  • After the scripted checks pass, do a short exploratory pass using normal input for 30-90 seconds instead of following only the intended path.
  • If the exploratory pass reveals a new state, control, or claim, add it to the shared QA inventory and cover it before signoff.
  • page.evaluate(...)
    may inspect or stage state, but it does not count as signoff input.
  • 使用真实用户控件进行验收：键盘、鼠标、点击、触摸或等效的Playwright输入API。
  • 验证至少一条端到端关键流程。
  • 确认该流程的可见结果，而非仅内部状态。
  • 针对实时或动画密集型应用，在实际交互时序下验证行为。
  • 按照共享QA清单执行检查，而非临时抽查。
  • 验收前至少覆盖每个明显可见的控件一次，而非仅覆盖主顺畅路径。
  • 针对清单中的可逆控件或有状态切换，测试完整周期：初始状态、变更后状态、返回初始状态。
  • 脚本化检查通过后，进行30-90秒的简短探索性检查，使用正常输入而非仅遵循预期路径。
  • 若探索性检查发现新状态、控件或承诺，将其添加到共享QA清单并在验收前覆盖。
  • page.evaluate(...)
    可用于检查或设置状态，但不视为验收输入。

Visual QA

视觉QA

  • Treat visual QA as separate from functional QA.
  • Use the same shared QA inventory defined before testing and updated during QA; do not start visual coverage from a different implicit list.
  • Restate the user-visible claims and verify each one explicitly; do not assume a functional pass proves a visual claim.
  • A user-visible claim is not signed off until it has been inspected in the specific state where it is meant to be perceived.
  • Inspect the initial viewport before scrolling.
  • Confirm that the initial view visibly supports the interface's primary claims; if a core promised element is not clearly perceptible there, treat that as a bug.
  • Inspect all required visible regions, not just the main interaction surface.
  • Inspect the states and modes already enumerated in the shared QA inventory, including at least one meaningful post-interaction state when the task is interactive.
  • If motion or transitions are part of the experience, inspect at least one in-transition state in addition to the settled endpoints.
  • If labels, overlays, annotations, guides, or highlights are meant to track changing content, verify that relationship after the relevant state change.
  • For dynamic or interaction-dependent visuals, inspect long enough to judge stability, layering, and readability; do not rely on a single screenshot for signoff.
  • For interfaces that can become denser after loading or interaction, inspect the densest realistic state you can reach during QA, not only the empty, loading, or collapsed state.
  • If the product has a defined minimum supported viewport or window size, run a separate visual QA pass there; otherwise, choose a smaller but still realistic size and inspect it explicitly.
  • Distinguish presence from implementation: if an intended affordance is technically there but not clearly perceptible because of weak contrast, occlusion, clipping, or instability, treat that as a visual failure.
  • If any required visible region is clipped, cut off, obscured, or pushed outside the viewport in the state you are evaluating, treat that as a bug even if page-level scroll metrics appear acceptable.
  • Look for clipping, overflow, distortion, layout imbalance, inconsistent spacing, alignment problems, illegible text, weak contrast, broken layering, and awkward motion states.
  • Judge aesthetic quality as well as correctness. The UI should feel intentional, coherent, and visually pleasing for the task.
  • Prefer viewport screenshots for signoff. Use full-page captures only as secondary debugging artifacts, and capture a focused screenshot when a region needs closer inspection.
  • If motion makes a screenshot ambiguous, wait briefly for the UI to settle, then capture the image you are actually evaluating.
  • Before signoff, explicitly ask: what visible part of this interface have I not yet inspected closely?
  • Before signoff, explicitly ask: what visible defect would most likely embarrass this result if the user looked closely?
  • 将视觉QA视为独立于功能QA的检查。
  • 使用测试前定义并在QA期间更新的共享QA清单；不要从不同的隐含列表开始视觉覆盖。
  • 重新陈述用户可见承诺并逐一明确验证；不要假设功能检查通过即证明视觉承诺成立。
  • 仅当在承诺对应的特定状态下进行检查后，用户可见承诺才能通过验收。
  • 滚动前检查初始视口。
  • 确认初始视图明确支持界面的主要承诺；若核心承诺元素在初始视图中不清晰可见，视为缺陷。
  • 检查所有需要可见的区域，而非仅主要交互区域。
  • 检查共享QA清单中已列举的所有状态和模式，若任务涉及交互，至少检查一个有意义的交互后状态。
  • 若体验包含动效或过渡，除稳定端点外，至少检查一个过渡中状态。
  • 若标签、覆盖层、注释、引导或高亮需跟踪变化内容，在相关状态变更后验证该关联关系。
  • 针对动态或依赖交互的视觉效果，检查足够长的时间以判断稳定性、层级和可读性；不要仅依赖单张截图进行验收。
  • 针对加载或交互后可能变得更密集的界面，检查QA期间可达到的最密集真实状态，而非仅空状态、加载状态或折叠状态。
  • 若产品定义了最低支持视口或窗口大小，在该尺寸下执行单独的视觉QA检查；否则，选择一个较小但仍真实的尺寸并明确检查。
  • 区分存在性与实现效果：若预期的交互元素技术上存在，但因对比度低、遮挡、裁剪或不稳定而不清晰可见，视为视觉失败。
  • 若在评估状态下，任何需要可见的区域被裁剪、截断、遮挡或推出视口，即使页面级滚动指标看起来正常，也视为缺陷。
  • 检查裁剪、溢出、变形、布局失衡、间距不一致、对齐问题、文本难以辨认、对比度低、层级断裂和动效状态异常。
  • 同时判断美学质量和正确性。UI应符合任务需求，具有目的性、连贯性和视觉吸引力。
  • 验收优先使用视口截图。仅将全页捕获作为次要调试产物，当需要近距离检查某区域时，捕获聚焦截图。
  • 若动效导致截图模糊，等待UI稳定后再捕获你实际评估的图像。
  • 验收前明确询问：此界面的哪个可见部分我尚未近距离检查？
  • 验收前明确询问：若用户仔细查看，哪个可见缺陷最可能让结果显得糟糕？

Signoff

验收

  • The functional path passed with normal user input.
  • Coverage is explicit against the shared QA inventory: note which requirements, implemented features, controls, states, and claims were exercised, and call out any intentional exclusions.
  • The visual QA pass covered the whole relevant interface.
  • Each user-visible claim has a matching visual check and reviewed screenshot artifact from the state and viewport or window size where that claim matters.
  • The viewport-fit checks passed for the intended initial view and any required minimum supported viewport size.
  • The UI is not just functional; it is visually coherent and not aesthetically weak for the task.
  • Functional correctness, viewport fit, and visual quality must each pass on their own; one does not imply the others.
  • A short exploratory pass was completed for interactive products, and the response mentions what that pass covered.
  • If screenshot review and numeric checks disagreed at any point, the discrepancy was investigated before signoff; visible clipping in screenshots is a failure to resolve, not something metrics can overrule.
  • Include a brief negative confirmation of the main defect classes you checked for and did not find.
  • Keep the final successful screenshot artifacts needed for evidence, and remove stale or superseded image artifacts from failed or intermediate runs.
  • 功能路径通过正常用户输入验证。
  • 覆盖范围明确对应共享QA清单：记录已验证的需求、已实现功能、控件、状态和承诺，并标注任何有意排除的内容。
  • 视觉QA检查覆盖了整个相关界面。
  • 每个用户可见承诺都有对应的视觉检查，以及来自该承诺相关状态、视口或窗口尺寸的已审核截图产物。
  • 针对预期初始视图和任何所需最低支持视口尺寸的视口适配检查通过。
  • UI不仅功能正常，还具有视觉连贯性，符合任务的美学要求。
  • 功能正确性、视口适配性和视觉质量必须分别通过检查；其中一项通过不代表其他项也通过。
  • 针对交互式产品完成了简短的探索性检查，反馈中需提及检查内容。
  • 若截图审核和数值检查在任何时候存在分歧，需在验收前调查差异；截图中可见的裁剪属于未解决的失败，不能用指标推翻。
  • 简要说明你检查过的主要缺陷类别且未发现问题。
  • 保留验收所需的最终成功截图产物，删除失败或中间运行产生的过时或被取代的图像产物。

Screenshot Capture

截图捕获

Use normal Playwright screenshots for evidence and debugging.
Desktop screenshot:
javascript
await page.screenshot({ path: 'playwright-desktop.png', type: 'png' });
Mobile screenshot:
javascript
await mobilePage.screenshot({ path: 'playwright-mobile.png', type: 'png' });
Clipped screenshot for a focused region:
javascript
const clip = await page.locator('[data-testid="target"]').boundingBox();
if (clip) {
	await page.screenshot({ path: 'playwright-target.png', type: 'png', clip });
}
Use viewport screenshots for signoff by default. Use full-page screenshots only as secondary debugging artifacts when needed.
使用常规Playwright截图作为证据和调试依据。
桌面端截图：
javascript
await page.screenshot({ path: 'playwright-desktop.png', type: 'png' });
移动端截图：
javascript
await mobilePage.screenshot({ path: 'playwright-mobile.png', type: 'png' });
聚焦区域的裁剪截图：
javascript
const clip = await page.locator('[data-testid="target"]').boundingBox();
if (clip) {
\tawait page.screenshot({ path: 'playwright-target.png', type: 'png', clip });
}
默认情况下，验收优先使用视口截图。仅在需要时将全页截图作为次要调试产物。

Viewport Fit Checks (Required)

视口适配检查（必填）

Do not assume a screenshot is acceptable just because the main widget is visible. Before signoff, explicitly verify that the intended initial view matches the product requirement, using both screenshot review and numeric checks.
  • Define the intended initial view before signoff. For scrollable pages, this is the above-the-fold experience. For app-like shells, games, editors, dashboards, or tools, this is the full interactive surface plus the controls and status needed to use it.
  • Use screenshots as the primary evidence for fit. Numeric checks support the screenshots; they do not overrule visible clipping.
  • Signoff fails if any required visible region is clipped, cut off, obscured, or pushed outside the viewport in the intended initial view, even if page-level scroll metrics appear acceptable.
  • Scrolling is acceptable when the product is designed to scroll and the initial view still communicates the core experience and exposes the primary call to action or required starting context.
  • For fixed-shell interfaces, scrolling is not an acceptable workaround if it is needed to reach part of the primary interactive surface or essential controls.
  • Do not rely on document scroll metrics alone. Fixed-height shells, internal panes, and hidden-overflow containers can clip required UI while page-level scroll checks still look clean.
  • Check region bounds, not just document bounds. Verify that each required visible region fits within the viewport in the startup state.
  • Passing viewport-fit checks only proves that the intended initial view is visible without unintended clipping or scrolling. It does not prove that the UI is visually correct or aesthetically successful.
Web or renderer check:
javascript
console.log(
	await page.evaluate(() => ({
		innerWidth: window.innerWidth,
		innerHeight: window.innerHeight,
		clientWidth: document.documentElement.clientWidth,
		clientHeight: document.documentElement.clientHeight,
		scrollWidth: document.documentElement.scrollWidth,
		scrollHeight: document.documentElement.scrollHeight,
		canScrollX: document.documentElement.scrollWidth > document.documentElement.clientWidth,
		canScrollY: document.documentElement.scrollHeight > document.documentElement.clientHeight
	}))
);
Augment the numeric check with 
getBoundingClientRect()
checks for the required visible regions in your specific UI when clipping is a realistic failure mode; document-level metrics alone are not sufficient for fixed shells.
不要仅因为主要组件可见就认为截图可接受。验收前，使用截图审核和数值检查明确验证预期初始视图是否符合产品需求。
  • 验收前定义预期初始视图。对于可滚动页面，这是首屏体验。对于类应用外壳、游戏、编辑器、仪表板或工具，这是完整交互区域加上使用所需的控件和状态信息。
  • 将截图作为适配性的主要证据。数值检查为截图提供支持，但不能推翻可见的裁剪。
  • 若预期初始视图中任何需要可见的区域被裁剪、截断、遮挡或推出视口，即使页面级滚动指标看起来正常，验收也不通过。
  • 当产品设计为可滚动且初始视图仍能传达核心体验并展示主要行动号召或所需起始上下文时，滚动是可接受的。
  • 对于固定外壳界面，若需要滚动才能到达部分主要交互区域或关键控件，滚动不能作为可接受的解决方案。
  • 不要仅依赖文档滚动指标。固定高度外壳、内部窗格和隐藏溢出容器可能会裁剪所需UI，而页面级滚动检查仍显示正常。
  • 检查区域边界，而非仅文档边界。验证启动状态下每个需要可见的区域是否适配视口。
  • 视口适配检查通过仅证明预期初始视图在无意外裁剪或滚动的情况下可见。不证明UI视觉正确或美学上成功。
Web或渲染器检查：
javascript
console.log(
\tawait page.evaluate(() => ({
\t\tinnerWidth: window.innerWidth,
\t\tinnerHeight: window.innerHeight,
\t\tclientWidth: document.documentElement.clientWidth,
\t\tclientHeight: document.documentElement.clientHeight,
\t\tscrollWidth: document.documentElement.scrollWidth,
\t\tscrollHeight: document.documentElement.scrollHeight,
\t\tcanScrollX: document.documentElement.scrollWidth > document.documentElement.clientWidth,
\t\tcanScrollY: document.documentElement.scrollHeight > document.documentElement.clientHeight
\t}))
);
当裁剪是可能的失败模式时，为特定UI中的所需可见区域添加
getBoundingClientRect()
检查以补充数值检查；仅文档级指标不足以覆盖固定外壳界面。

Dev Server

开发服务器

For local web debugging, keep the app running in a persistent TTY session. Do not rely on one-shot background commands from a short-lived shell.
Build first, then start the built app on port 
4444
only:
bash
npm run build
PORT=4444 npm run start
Before 
page.goto(...)
, verify port 
4444
is listening and the app responds.
  • After interactive verification is complete, stop the server process you started on port 
    4444
    so the sandbox stays clean for the rest of the task.
  • fuser
    is not available in this Debian sandbox. Use 
    ss -ltnp | rg ":4444"
    to find the listening PID, then 
    kill <pid>
    , then rerun 
    ss -ltnp | rg ":4444"
    to confirm port 
    4444
    is no longer listening.
  • Remove stale or superseded interactive image artifacts after cleanup so only the final successful evidence remains.
  • After interactive verification is complete, stop the server process you started on port 
    4444
    so the sandbox stays clean for the rest of the task.
  • fuser
    is not available in this Debian sandbox. Use 
    ss -ltnp | rg ":4444"
    to find the listening PID, then 
    kill <pid>
    , then rerun 
    ss -ltnp | rg ":4444"
    to confirm port 
    4444
    is no longer listening.
  • After interactive verification is complete, stop the server process you started on port 
    4444
    so the sandbox stays clean for the rest of the task.
对于本地Web调试，在持久化TTY会话中保持应用运行。不要依赖短命shell中的一次性后台命令。
先构建，再仅在端口
4444
启动构建后的应用：
bash
npm run build
PORT=4444 npm run start
在
page.goto(...)
之前，验证端口
4444
正在监听且应用可响应。
  • 交互式验证完成后，停止你在端口
    4444
    启动的服务器进程，保持沙箱干净以完成后续任务。
  • 此Debian沙箱中没有
    fuser
    。使用
    ss -ltnp | rg ":4444"
    查找监听PID，然后执行
    kill <pid>
    ，再重新运行
    ss -ltnp | rg ":4444"
    确认端口
    4444
    不再监听。
  • 清理后删除过时或被取代的交互式图像产物，仅保留最终成功的证据。
  • 交互式验证完成后，停止你在端口
    4444
    启动的服务器进程，保持沙箱干净以完成后续任务。
  • 此Debian沙箱中没有
    fuser
    。使用
    ss -ltnp | rg ":4444"
    查找监听PID，然后执行
    kill <pid>
    ，再重新运行
    ss -ltnp | rg ":4444"
    确认端口
    4444
    不再监听。
  • 交互式验证完成后，停止你在端口
    4444
    启动的服务器进程，保持沙箱干净以完成后续任务。

Common Failure Modes

常见失败模式

  • Cannot find module 'playwright'
    : ensure the 
    playwright
    package is installed in the current workspace and verify the import before running the Node.js script.
  • Playwright package is installed but the browser executable is missing: run 
    npx playwright install chromium
    .
  • page.goto: net::ERR_CONNECTION_REFUSED
    : make sure the dev server is still running in a persistent TTY session, recheck the port, and prefer 
    http://127.0.0.1:<port>
    .
  • The Node.js process exited or reset unexpectedly: rerun the verification script from a clean process.
  • Cannot find module 'playwright'
    ：确保
    playwright
    包已安装在当前工作区，并在运行Node.js脚本前验证导入。
  • Playwright包已安装但浏览器可执行文件缺失：运行
    npx playwright install chromium
    。
  • page.goto: net::ERR_CONNECTION_REFUSED
    ：确保开发服务器仍在持久化TTY会话中运行，重新检查端口，优先使用
    http://127.0.0.1:<port>
    。
  • Node.js进程意外退出或重置：从干净进程重新运行验证脚本。 ",