Playwright快速入门：从安装到实战的端到端测试指南

Playwright 这个词，我在自动化测试圈子里已经听了太多遍，刚开始我还不以为然，觉得无非又是一个“看起来很美”的测试框架。但当我真正在项目里把它从安装到落地跑完一条完整的业务链路之后，才意识到这东西确实有东西。如果你正在纠结选哪个端到端测试工具，或者刚接触自动化测试被各种概念绕得头晕，这篇《Playwright快速入门：从安装到实战应用》应该能帮你省下不少时间。我会从零开始讲，不预设你有任何基础，但也不会废话连篇，力求每一步都能直接照着做。

1. 为什么是Playwright：核心优势与适用场景

1.1 它到底解决了什么问题

端到端测试一直是软件质量保障里最头疼的一环。早年间的自动化方案，要么因为脚本运行不稳定被团队放弃，要么因为选择器太脆弱导致日常维护成本居高不下，要么就是并发执行能力太弱，跑一次全量回归要一两个小时，CI流水线根本不敢塞进去。Playwright的出现，很大程度上是冲着这三个痛点去的：跨浏览器、快速、稳定。

它的底层架构和我之前用的老牌工具不一样。Playwright通过一套独立的协议直接与浏览器实例通信，而不是依赖古老的WebDriver接口。这条协议通道更轻量、更高效，而且它支持Chromium、Firefox、WebKit三套浏览器内核。需要注意，这里说的是WebKit，也就是苹果Safari所用的内核，这也就是说你可以在Windows、Linux机器上直接测WebKit的表现，不需要非得有一台Mac。这一点对于兼容性测试的意义，用过的都懂。

另一个让我彻底改观的地方，是它对“自动等待”的处理。以前写自动化，最烦的就是各种sleep(2),sleep(3)，时间短了元素没加载出来，时间长了白等。Playwright内置了一套可操作性判断机制，元素要可点击、可见、稳定之后再去执行操作，省掉了我至少一半的等待和重试代码。

1.2 和同类工具的横向对比

很多刚接触的朋友会问我：既然我手头的工具也能做端到端测试，为什么要换？我用一个比较直观的方式来说明。

表格只能说明功能差异，实际体验上的差距更明显。就拿录制脚本来说吧，Playwright的codegen命令不光能录制点击、输入这些操作，它生成的代码还是“定位器优先”的现代写法，而不是一堆一改就碎的XPath。这个设计思路很聪明，等于说工具在引导你写出更健壮的测试代码，防患于未然。

适用场景方面，我的感受是：如果你团队已经有了一套跑得不错的UI自动化体系，换不换都行；但如果你是从零搭一套端到端测试，或者现有方案稳定性让你天天凌晨爬起来看失败任务，那Playwright值得认真考察。它对于中小团队尤其友好，因为不需要额外搭一套Grid之类的东西来管理浏览器集群，它原生支持并行，跑起来又快又省事。

2. 安装与环境准备：从零开始搭一套可用环境

2.1 两种常见的技术栈选型

Playwright官方支持JavaScript/TypeScript和Python两种主流语言绑定，另外也实验性支持Java和.NET。实际工作中，前端团队用Node.js版最顺手，因为和现有前端技术栈无缝衔接；测试团队如果主力语言是Python，直接用Python版也很顺。

我这里两条路都讲一下，你根据自己的情况选一条就行。

Node.js路线的安装命令是：

npm init playwright@latest

这个命令会帮你初始化项目结构并创建示例配置文件。如果你是想往已有项目里加测试能力，也可以分开执行：

npm install -D @playwright/test

Python路线则直接使用pip：

pip install pytest-playwright

注意我这里加的是pytest-playwright，它是一个pytest插件，安装之后可以把Playwright的能力直接以fixture形式注入到测试用例里，配合pytest的组织能力和断言风格，写起来很舒服。如果只要裸的Playwright，那pip install playwright就够了，但实际项目里我基本都是配合pytest用的。

2.2 安装浏览器内核这一步容易栽跟头

代码包安装完之后，还有一个关键步骤：下载浏览器内核。很多人以为装完npm包就万事大吉了，直接跑脚本然后报错找不到浏览器，一脸茫然。

Node.js版执行：

npx playwright install

Python版执行：

playwright install

这个命令会把Chromium、Firefox、WebKit三套内核全部下载到本机的用户目录下。具体路径在Windows是%USERPROFILE%\AppData\Local\ms-playwright，在Linux和macOS是~/Library/Caches/ms-playwright（macOS）或~/.cache/ms-playwright（Linux）。

这里有几个容易踩的坑，我逐个说：

第一，下载可能因为网络问题失败。如果多次失败，可以用镜像环境变量来加速，Node版设置PLAYWRIGHT_DOWNLOAD_HOST，Python版设置PLAYWRIGHT_DOWNLOAD_HOST或者直接配置pip镜像源。一句经验：先检查是否因为没配镜像源导致的超时，不要一上来就怀疑代码写错了。

第二，在公司内网环境，可能需要设置代理才能下载成功。如果装了防火墙策略，更稳妥的做法是让网络管理员放行上述下载域名。

第三，只需要某一种浏览器的话，可以按需安装。比如你确定只跑Chromium，那装一个就行：

npx playwright install chromium

这样能省不少磁盘空间和下载时间。我个人的习惯是开发机只装Chromium，CI那台机器才三个内核全装，因为很多兼容性问题是不会在本地提前暴露的。

2.3 命令行验证环境是否就绪

安装完成之后，不急着写代码，先跑一条最简单的命令验证环境。在项目根目录创建第一个测试文件first.spec.js（Node版）或test_first.py（Python版），内容就写打开一个页面然后断言标题。

Node版：

const { test, expect } = require('@playwright/test'); test('环境验证测试', async ({ page }) => { await page.goto('https://example.com'); await expect(page).toHaveTitle(/Example/); });

Python版：

from playwright.sync_api import Page, sync_playwright def test_env_ok(page: Page): page.goto("https://example.com") assert page.title() == "Example Domain"

Node版直接运行npx playwright test，Python版运行pytest。如果控制台没有任何报错，说明从依赖安装到浏览器内核下载全都正常，可以进入下一步学习核心概念了。

我见过太多人一开始就卡在这一步，所以刻意把这个平时很少人细致讲的环境验证环节单独拿出来说。环境问题不解决，后面所有代码都跑不起来，先把地基打好比什么都重要。

3. 核心概念：定位器、自动等待与断言机制

3.1 现代定位器语法：告别脆弱的选择器

刚接触Playwright的很多人会被“Locator”这个概念绕晕。其实说白了，定位器就是你对页面上某个元素的位置描述。重点在于，它不像传统工具那样只能依赖XPath或CSS去“钻”元素的层级结构，而是提供了一批面向用户感知层面的定位方式。

拿最常见的登录框举例。传统XPath写法可能是//*[@id="username"]或者更恐怖的/html/body/div[2]/form/div[1]/input。前者勉强能忍，后者只要页面结构动一点就挂了。Playwright推荐的是这种写法：

await page.getByLabel('用户名').fill('tester01'); await page.getByRole('button', { name: '登 录' }).click();

page.get_by_label("用户名").fill("tester01") page.get_by_role("button", name="登 录").click()

getByRole是我使用频率最高的API。它基于无障碍树来定位元素，按钮就是按钮，链接就是链接，输入框就是输入框。它的好处在哪儿呢？页面视觉重构了，但按钮的功能没变，角色和名字还是那些，测试脚本就不会受到牵连。这相当于把测试从“绑定具体长相连结”换成了“绑定功能语义”，健壮性自然上了一个台阶。

其他的常用定位器还有：

• getByText('文本内容')：适合定位带指定文本的元素。
• getByPlaceholder('请输入手机号')：按占位符文本定位输入框。
• getByTestId('submit-btn')：按>await expect(page.getByText('订单提交成功')).toBeVisible();

  Python版类似：

  from playwright.sync_api import expect expect(page.get_by_text("订单提交成功")).to_be_visible()

  这种断言的底层逻辑是：它不会立刻判断，而是会在默认5秒内持续重试，直到元素可见、文本匹配或者到达超时时间。这个机制让“接口还在返回、页面还没刷新完”这类异步时序问题不再是脚本崩溃的元凶，而是被自动消化掉了。

  常用的断言我整理了几个：

  断言场景	Node写法	Python写法
  元素可见	toBeVisible()	to_be_visible()
  元素包含文本	toContainText('xxx')	to_contain_text("xxx")
  输入框有值	toHaveValue('xxx')	to_have_value("xxx")
  页面地址	toHaveURL('**/login')	to_have_url("**/login")
  元素数量	toHaveCount(3)	to_have_count(3)

  这套断言体系让我觉得“测试代码”终于像“代码”而不是“按脚本执行的操作清单”了。它的容错能力直接决定了你在半夜收到的失败通知会少很多——因为大多数失败都是假的，都是时序问题。

  4. 实战应用：完成一条完整的业务链路测试

  4.1 使用codegen快速录制脚本

  理论知识说再多，不如动手跑一遍。这里我带你走一个完整的实战流程，场景就用“登录商城→搜索商品→加入购物车→结算”这条主链路。

  第一步是使用录制工具。在项目目录下运行：

  npx playwright codegen

  Python版：

  playwright codegen

  命令跑起来之后，会弹出一个带有开发者工具的浏览器窗口，同时还有一个独立的“Playwright Inspector”面板。你在浏览器里的每一步操作——点击、输入、滚动——都会被实时翻译成对应代码，出现在旁边面板里。

  这一步对于快速确认业务场景、提取关键操作路径非常有用。我自己现在即便是写很复杂的用例，也会先用codegen把主路径跑一遍，拿到基础骨架，再在此基础上补断言、补异常分支。这个习惯大幅节约了“一边看页面一边写选择器”的时间，实测下来写一个完整用例的速度至少快一倍。

  需要提醒一点：录制生成的代码可以直接用，但它未必是最优的。比如下拉选择这种交互，你手动点击打开的，录制出来可能是“点击→点击选项”两步，实际上用selectOption一步就能搞定，而且更稳定。对于复杂的异步交互，比如上传文件、跨域iframe等，建议录制之后手动修改成更精准的API调用。

  4.2 从骨架到完整用例：补充断言与逻辑

  假设录制出来的核心操作代码是打开页面、点登录按钮、输入账号密码、点搜索、点击商品、加入购物车、点结算。接下来需要把它组织成一个可读性高、有实际校验能力的完整用例。

  Node版最终形态：

  const { test, expect } = require('@playwright/test'); test('商城购物主链路', async ({ page }) => { // 打开商城首页 await page.goto('https://shop.example.com'); await expect(page).toHaveTitle(/商城/); // 登录 await page.getByRole('button', { name: '登录' }).click(); await page.getByLabel('用户名').fill('standard_user'); await page.getByLabel('密码').fill('secret_sauce'); await page.getByRole('button', { name: '确认登录' }).click(); await expect(page.getByText('欢迎回来')).toBeVisible(); // 搜索商品 await page.getByPlaceholder('搜索商品').fill('无线鼠标'); await page.keyboard.press('Enter'); await page.getByText('无线鼠标').first().click(); // 加入购物车 await page.getByRole('button', { name: '加入购物车' }).click(); await expect(page.getByText('购物车(1)')).toBeVisible(); // 结算 await page.getByRole('button', { name: '去结算' }).click(); await page.getByRole('button', { name: '提交订单' }).click(); await expect(page.getByText('订单提交成功')).toBeVisible(); });

  Python版对应：

  from playwright.sync_api import Page, expect def test_shopping_main_flow(page: Page): page.goto("https://shop.example.com") expect(page).to_have_title("商城") page.get_by_role("button", name="登录").click() page.get_by_label("用户名").fill("standard_user") page.get_by_label("密码").fill("secret_sauce") page.get_by_role("button", name="确认登录").click() expect(page.get_by_text("欢迎回来")).to_be_visible() page.get_by_placeholder("搜索商品").fill("无线鼠标") page.keyboard.press("Enter") page.get_by_text("无线鼠标").first.click() page.get_by_role("button", name="加入购物车").click() expect(page.get_by_text("购物车(1)")).to_be_visible() page.get_by_role("button", name="去结算").click() page.get_by_role("button", name="提交订单").click() expect(page.get_by_text("订单提交成功")).to_be_visible()

  这个用例的结构很清晰，每一步操作之后紧跟着一个断言，每过一个关键节点就确认“确实到了预期状态”，而不是一口气把所有操作做完再回头查结果。这是一种非常重要的风格习惯：断言不要只关注最终结果，中间每个关键节点都值得加一道“关卡”。

  4.3 运行与结果分析

  跑用例只需要一行命令：

  npx playwright test

  Python版本：

  pytest

  运行完成后，控制台会打印出通过/失败情况。默认配置下，Playwright会在test-results目录生成运行报告。如果用例失败了，它会自动截取失败当刻的页面截图，同时保留一份完整的HTML报告供你查看。

  这里要特别看一下失败时的信息。它不只是告诉你“断言失败”，还会高亮出是第几行代码对应的问题，比如定位器找到了多少个元素、为什么元素没有可见等，这些信息对于定位生活问题非常重要。

  我强烈建议养成习惯：每次跑完用例之后，花一分钟打开HTML报告，即使全部通过也扫一眼页面截图和各步操作耗时。这样能提前发现潜在的慢交互或者不稳定的状态变化，不至于等问题爆发了才去找原因。

  5. 工程化要点：配置文件、并行执行与调试

  5.1 配置文件：一张表管住所有运行参数

  测试项目一旦规模上来，配置文件的地位就凸显了。Playwright官方推荐在项目根部放置配置文件，Node版是playwright.config.js，Python版通常写在pytest.ini或playwright.config相关的pytest插件配置中。

  Node版的示例配置：

  // playwright.config.js const { defineConfig } = require('@playwright/test'); module.exports = defineConfig({ testDir: './tests', timeout: 30000, retries: 2, workers: 4, // 并行worker数 reporter: [ ['html', { outputFolder: 'playwright-report' }], ['list'] ], use: { baseURL: 'https://shop.example.com', headless: true, viewport: { width: 1280, height: 720 }, screenshot: 'only-on-failure', trace: 'retain-on-failure' }, projects: [ { name: 'chromium', use: { browserName: 'chromium' } }, { name: 'firefox', use: { browserName: 'firefox' } }, { name: 'webkit', use: { browserName: 'webkit' } } ] });

  几个关键参数我解释一下：

  retries是失败任务重试次数。这个参数非常有实际价值，尤其是处理偶发性失败时。但它不能设置太高，否则会掩盖真实问题，我一般设1～2次。

  workers是并行执行的进程数。默认等于机器CPU核心数的一半，你可以根据CI机器的配置手动调整。并行数量不是越多越好，因为每个worker会拉起来一个浏览器实例，内存占用不容小觑，设置太高容易OOM。

  trace是调试追踪的开关，这个后面单独说，我先卖个关子。

  projects里面定义的是不同浏览器的运行矩阵。这个配置跑一次会在三套浏览器各执行一遍用例，对于需要兼容主流浏览器的项目来说是不可或缺的。不需要全浏览器覆盖的就删掉多余项目，只保留所需的那一个。

  Python版可以在pytest.ini里找到着落点：

  [pytest] # 指定测试文件目录 testpaths = tests # 使用无头模式 addopts = --headed=false

  如果用了pytest-playwright插件，它默认支持通过命令行参数控制浏览器种类，比如pytest --browser chromium --browser firefox -n 4，其中-n 4是利用pytest-xdist插件实现的并行。

  5.2 并行执行：CI流水线不再排队

  并行执行是自动化测试走向工程化的重要一环。很多团队不敢在CI里跑UI测试，就是因为串行跑动辄一两个小时，相当于占用了一条流水线整整半天。Playwright默认就支持多worker并行，不需要额外引入Selenium Grid这种重量级方案。

  你只需要在配置中指定workers的数量，或者命令行传--workers=4，框架会把不同测试文件分配到不同worker里去并行执行。

  需要注意一点：并行执行的worker之间是相互隔离的，每个worker有自己的浏览器实例和页面上下文，互不干扰。但你的测试代码不能依赖共享的本地文件状态，比如写文件到固定路径，不然并行时会出现竞态条件。需要写临时数据的话，用testInfo.outputPath或者tmp_path这类隔离路径。

  并行之后还有一个隐性收益，就是整个测试套件的运行时间从“所有用例相加”变成了“最慢的那个worker的用例之和”，理论上能把整个回归时间压缩到原来的1/N。我自己在项目里的实际体验是：200条用例从串行的50多分钟压到了15分钟内跑完，这个时间对于CI流水线来说就完全可接受了。

  5.3 调试利器：Trace Viewer与调试模式

  调试环节是Playwright体验里最加分的地方。它内置的Trace Viewer可以帮你回放整个测试过程，不仅能看到每步操作前后的页面截图，还能看到网络请求、控制台日志、DOM快照等全量信息。

  开启trace非常简单，不用改代码。在配置里把trace设置成'retain-on-failure'，这样只在失败时保留trace文件。想临时调试某一个用例时，也可以命令行开启：

  npx playwright test --trace on

  跑完之后，控制台会输出一个trace文件路径，执行：

  npx playwright show-trace trace.zip

  就能在浏览器里打开一个可视化的时间轴。你可以拖到任何一步，查看当时的页面状态和控制台报错，甚至可以点击网络请求看返回体。这些排查手段对于“用例在我机器上过、一上CI就挂”的问题特别有效，因为CI上的报错往往信息有限，trace却能还原完整现场。

  另外一个我常用来调试的方式是设置环境变量PWDEBUG=1，这能进入Playwright的调试模式。在这个模式下，脚本会变成“单人操作模式”，每一步执行前会暂停，并高亮当前操作的元素，控制台还会输出对应的API调用信息。我一般在排查定位器问题时会开这个模式，因为它能直接在终端里看到定位器匹配到了哪些元素，非常直观。

  6. 常见问题与排查技巧实录

  6.1 元素定位到了但点击无效

  这是我在群里看到被问得最多的问题。表面现象是：定位器没报找不到元素，但点击后页面没有任何反应，测试也没有失败。

  这种情况八成是页面在点击时发生了异步跳转或者弹窗拦截。例如，某个按钮在点击一瞬间还在加载状态，或者点击事件被外层遮罩挡住了。很多老手第一个反应是去看控制台有没有异常，其实更快的路径是打开Trace Viewer看点击那一步的页面快照，确认你看到的和浏览器实际渲染的是否一致。

  另一种常见原因是点击之后页面并没有按照预期跳转，而是触发了某个你没注意到的前端校验。此时建议把断言细化：不要只断言“最终结果可见”，而是对点击后的URL变化、元素STYLE变化做中间断言，快速缩小范围。我自己的排查顺序是：先看Trace快照，再看控制台日志，然后手动操作一遍页面复现。三步走下来，90%的问题都能定位。

  6.2 下载浏览器失败或超时

  这个问题在安装章节已经提过，但我在实践中发现它其实远不止“网络不好”那么简单。有时公司内网的沙箱环境会拦截外部连接，有时是某台CI机器的磁盘空间不够导致下载中途失败，有时甚至是因为版本不一致导致缓存目录里的浏览器和当前库版本不匹配而自动触发重新下载。

  最直接的排查方式：删掉用户的ms-playwright缓存目录重新执行install命令。如果依然失败，检查网络代理配置，确保PLAYWRIGHT_DOWNLOAD_HOST指向的内部镜像源地址有效。还有一点，如果你是在CI里用Docker镜像跑的，务必给镜像预留至少2GB的可用空间，否则下载到一半磁盘满了，报错信息会很迷惑。

  6.3 常用问题速查表

  现象	可能原因	推荐做法
  找不到元素	页面未加载完成、选择器错误	检查定位器语法，增加中间断言
  点击无效	元素被遮罩、异步校验拦截	打开trace回看快照，检查控制台日志
  测试偶尔失败	时序问题、网络波动	配置合理重试次数，优化定位器使用
  下载浏览器超时	网络限制、磁盘不足	配置镜像源，清理缓存目录，扩充磁盘
  并行运行内存溢出	worker数量过多	减少workers数量，增加CI实例内存
  iframe内元素定位不到	页面跨域iframe结构	使用page.frameLocator()定位iframe内元素
  跑完没有报告	reporter配置未生效	检查配置文件路径和reporter参数

  6.4 一个容易被忽视的细节：浏览器关闭时机

  还有一个小细节可能让你在本地跑没问题、CI一跑就出诡异错误：用例结束时Playwright默认会立即关闭浏览器上下文。如果你的用例里有异步请求还没有完全结束，比如一个表单提交后页面要等待后端响应才能刷新，那最后的断言必须放在操作之后的等待期内。正确的姿势是依赖断言自动重试去“等待最终状态”，而不是在代码里盲目加等待。

  这里说一个我自己总结的“稳定用例三条军规”：

  第一，每条用例只测一个完整业务路径，中间不要插入无关步骤；第二，操作后立即加断言，不要等到用例末尾才一次性验证；第三，凡是涉及异步加载的部分，一律交给自动等待机制，自己不要手写sleep。遵守这三条，你的用例稳定性至少能提升一个档次。

  7. 进阶技巧与团队落地建议

  7.1 保存登录状态的两种姿势

  很多系统的登录流程比较重，比如有短信验证码、图形验证码，如果每条用例都走一遍登录流程，不但慢，还容易因为验证码问题导致批量失败。聪明的做法是把登录状态“缓存”下来复用。

  Playwright提供两套方案。第一套是保存storageState，专门用于保存cookie和localStorage等会话信息。先写一个登录用例，成功登录后执行：

  await page.context().storageState({ path: 'auth.json' });

  后续用例通过配置加载这个文件就能直接“带着登录态”打开页面，省掉整条登录流程。Python写法类似：

  context.storage_state(path="auth.json")

  另一套方案是自己封装登录fixture，适合登录流程比较复杂、且需要多次刷新token的场景。本质上是在beforeAll或session级别的fixture里执行登录，然后把页面上下文对象传递到组内的每一条用例中。这种做法的可控性更强，但代码复杂度也更高。我的建议是先从storageState上手，它覆盖了80%的需求。

  7.2 视觉回归测试：一个有用的补充

  Playwright还内置了截图对比能力，算是视觉回归测试的基础设施。在关键页面或者关键交互之后，可以调用expect(page).toHaveScreenshot()，框架会自动把当前页面截图和基线版本对比，像素级不一致就会让用例失败。

  这个功能在样式变更频繁的前端项目里很实用，但也容易误报。比如页面上有动态广告或者日期控件，每次截图内容都有细微差异，结果整条用例天天失败。所以使用时一定要先确定目标页面的“稳定性”。我的经验是：视觉回归只用在核心页面，比如首页、支付页、个人中心，不要把整个系统的每一页都纳入，不然维护基线图的成本会把你压垮。

  7.3 团队落地：从一个人用到一个组都用起来

  单打独斗地写用例很容易，难的是让一个团队的UI自动化产出稳定、可控、可持续演进。我见过不少项目刚开始红红火火地写了几百条用例，两个月后就因为没人维护变成了无人问津的“遗产代码”。

  要避免这种结局，我总结了几条落地心得：

  一、用例命名务必语义化。像login_success.spec.js这样的名字就比test1.spec.js好得多，因为别人看名字就知道它在测什么。二、把公共操作封装成Page Object或者工具函数，不要把一堆重复的点击步骤散落在每条用例里。三、定好运行频率和触发时机，不是所有用例都要跑在每个commit上，可以区分冒烟集和全量回归集，前者跑主流程，后者跑全量。四、做好失败分析机制，每次失败都要有人跟进，是环境问题就去修环境，是代码问题就去提单，绝不能看一眼截图就“re-run”糊弄过去。

  技术选型固然重要，但团队的执行习惯和规范才是这套体系能否长久运转的关键。Playwright只是把工具的下限拉高了，上限还是靠团队的工程化水平决定的。

  8. 写在最后的一些实操体会

  从第一次在终端敲下npm init playwright@latest到现在，我大概已经写了上千条用例。如果非要我总结一句最核心的体会，那就是：Playwright把“稳定”这个原本最难做到的事情，内化到了框架设计里。

  自动等待、Web-first断言、内置重试、Trace调试、并行执行，这些能力单独看都是小点，合在一起却改变了自动化测试的整个工作方式。以前我花大量时间处理“等多久才合理”的玄学问题，现在我把这些时间花在了业务断言的覆盖和场景设计的打磨上，这本身就是一件很划算的事。

  如果你准备在团队里引入它，我的建议是从一条最核心的业务链路开始，不要贪多，先让它跑起来、跑稳定，再一步步扩大覆盖面。环境配置到测试落地前两三天的摩擦期是正常的，过了这个坎，后续的边际成本会直线下降。

  最后再分享一个小技巧，很多人不知道：npx playwright test --debug可以直接以调试模式启动用例，配合编辑器里的断点，可以在用例执行到中间某一行时暂停并检查页面状态。这个功能在排查复杂逻辑用例时特别好用，相当于给测试代码也装了一个DevTools。生产环境里遇到什么诡异问题，先别急着怀疑框架，开着调试模式把页面亲手走一遍，答案往往就浮出水面了。