Playwright 四种语言绑定的能力差异：不是每个特性都有
选语言这件事，多数团队没得选——后端是 Java 的就得写 Java，数据同学清一色 Python。真正要问的不是「哪种绑定更好」，而是「我这一侧会缺什么，缺的那部分什么时候会咬到我」。
Playwright 仓库把答案写在 docs/src/languages.md 的开头一句里：多种语言共享同一套底层实现，浏览器自动化的核心能力在所有语言里都支持，不同的是测试生态的集成（原文表述为 testing ecosystem integration）。这句话是整篇文章的分界线：往下的差异，几乎全部落在「测试运行器以及运行器附带的东西」上，而不是「能不能点这个按钮」。
第一层分叉：谁给你测试运行器
四个绑定在这一层的答案完全不同，而且都写在各自的入口文档里。
- JavaScript / TypeScript：
docs/src/intro-js.md开头写明 Playwright Test 是一套端到端测试框架，把 test runner、断言、隔离、并行和工具链打包在一起。也就是说运行器是 Playwright 自己的。 - Python：
docs/src/intro-python.md明确说本篇介绍的是 Playwright Pytest plugin，并称它是编写端到端测试的推荐方式；运行器是 Pytest，Playwright 提供插件。docs/src/test-runners-python.md是这个插件的参考页。 - Java：
docs/src/test-runners-java.md的措辞是「用几行代码把 Playwright 接到你喜欢的 Java 测试运行器上」，正文给的是 JUnit 里在@BeforeAll建Playwright与Browser、在@AfterAll销毁的写法。Playwright 这边不提供运行器。 - .NET：
docs/src/test-runners-csharp.md写明 Playwright for .NET 不绑定某个运行器，但提供了 MSTest、NUnit、xUnit、xUnit v3 的基类，这些基类负责跑多浏览器引擎、调整 launch/context 选项、每个测试拿到一个Page/BrowserContext。
这一层决定了后面所有事。运行器归谁，运行器带来的能力就归谁。
第二层：只有 JS 侧才有的那一批
docs/src/ 里文件名带 -js 后缀的是 JS 专属页。把和运行器相关的那些页拉出来看，缺口就很清楚了。
运行器 API 整体是 JS 专属。 docs/src/test-api/ 下的 class-fixtures.md、class-test.md、class-testconfig.md、class-testproject.md、class-testinfo.md 这些文件，类定义那几行标着 * langs: js。docs/src/test-reporter-api/ 下的 class-reporter.md 等同理。这意味着 fixture、projects、retries、sharding、自定义 reporter 这一整套概念，在其它三种语言里没有对应的 Playwright API——不是「写法不同」，是这层东西根本不在那些绑定的职责范围内，得由 Pytest / JUnit / NUnit 各自的机制去补。
UI Mode 只有 JS 侧。 docs/src/test-ui-mode-js.md 给的开启方式是：
npx playwright test --ui
在 docs/src/ 里搜 --ui，出现它的文件只有 JS 侧那几个（intro-js.md、running-tests-js.md、test-cli-js.md、test-ui-mode-js.md 以及 JS 的发布说明）。Python、Java、.NET 的对应文档里我们没有找到 UI Mode 的入口。这是最容易被误判的一条：很多人看演示视频以为这是 Playwright 的通用功能，实际上它挂在 JS 的运行器上。
组件测试只有 JS 侧，而且形态刚变过。 docs/src/test-components-js.md 写明组件测试就是一个普通的端到端测试，跑在你自己 dev server 提供的 story gallery 页面上，靠 @playwright/test 内置的 mount fixture 驱动，没有专门的组件测试运行时、没有打包器集成。同一页有一条 note 明确写着：实验性的 @playwright/experimental-ct-react、-ct-react17、-ct-vue 包已经移除、不再发布，文档里给了迁移指引。文档自述这套实验包长期停留在 experimental 的原因有两条：它要接管整条编译链路，只有当你的构建配置和它一致时才能用；以及 Node.js 与浏览器之间的边界会泄漏。这两条是仓库文档自己写的，我不替它引申。
部分断言也是 JS 专属。 docs/src/api/class-genericassertions.md 与 class-snapshotassertions.md 的类定义标着 * langs: js，前者是 toBe、toEqual、toThrow 这类通用值断言，后者对应截图快照。docs/src/test-assertions-js.md 里的 toHaveScreenshot 也只出现在 JS 侧文档。另外 class-coverage.md、class-browserserver.md 同样标 langs: js。
第三层：四语言都有，但走法不同
不要把上面那串缺口理解成「其它语言是二等公民」。定位器、页面操作、网络拦截这些核心 API 四语言齐备，差异在于同一个能力的入口不同。trace 是最典型的例子。
- Python 侧（
docs/src/trace-viewer-intro-java-python.md）：用 Pytest 插件时靠命令行开关，文档里--tracing的取值是on/off/retain-on-failure，产物落到test-results目录下的trace.zip；不用 Pytest 就自己调context.tracing.stop(path = "trace.zip")这一套。 - Java 与 .NET（同上一页的 Java 部分、
docs/src/trace-viewer-intro-csharp.md）：没有插件替你做，直接用BrowserContext.tracing的 start/stop API，.NET 侧写作Context.Tracing.StartAsync(...)与Context.Tracing.StopAsync(...)。 - 打开 trace 的命令也各不一样。Python 侧是
playwright show-trace trace.zip；Java 侧文档给的是通过 Maven 调 CLI 主类：
mvn exec:java -e -D exec.mainClass=com.microsoft.playwright.CLI -D exec.args="show-trace trace.zip"
.NET 侧走的是安装时生成的 PowerShell 脚本，playwright.ps1 show-trace <你的 trace 文件>。这一条对 Windows 用户尤其要留意：.NET 绑定的 CLI 入口就是 .ps1，需要 pwsh 来跑；而 Python 侧装完插件后直接就有 playwright 命令，两边的心智模型不一样。
并行也是同一回事。JS 侧由运行器自己管；Python 侧 docs/src/test-runners-python.md 指向 pytest-xdist（pip install pytest-xdist）；.NET 侧交给运行器参数，文档给的 NUnit 例子是 dotnet test -- NUnit.NumberOfTestWorkers=5（这是仓库文档里的示例值，不是推荐配置）；同一页还写明 NUnit 下只支持 ParallelScope.Self。
面向编码 agent 的那条线倒是跨语言的：docs/src/getting-started-cli.md 写明可以全局安装独立 CLI 包，并注明它「works with any language」。
第四层：反过来 JS 缺的东西
差异不是单向的，有几个类在文档里明确标了不含 js：
| 类 | langs 标记 |
|---|---|
FormData | java, csharp, python |
RequestOptions | java |
PlaywrightException | java |
Error | python |
CDPSessionEvent | csharp |
WebSocketFrame | csharp, java |
PlaywrightAssertions | js, java, csharp |
最后一行值得多看一眼：docs/src/api/class-playwrightassertions.md 的类定义标的是 js, java, csharp，没有 python——Python 侧的 expect 是直接从模块导入的，不走这个静态类。这类差异属于语言习惯的映射，不是能力缺失，但你从 Java 示例往 Python 迁写法时会一头撞上。
软断言的情况相反：docs/src/test-assertions-csharp-java-python.md 里「Soft assertions」那一节标着 * langs: python，同一页的「Custom Expect Message」标的是 python, csharp。也就是说在这份三语言合并的文档里，Java 侧我们没有找到软断言的对应说明。这一点我只陈述文档现状，不推断 Java 侧到底有没有。
线程模型：两条硬边界
docs/src/threading-java.md 写得很直白：Playwright Java 不是线程安全的，Playwright 对象及其创建出来的 Browser、BrowserContext、Page 都应当在创建 Playwright 对象的那个线程上调用，否则要自己做同步；可以每个线程各建一个 Playwright 实例。
Python 侧在 docs/src/library-python.md 的 Known issues 一节里有对应说法：API 不是线程安全的，多线程环境下应该每个线程建一个 playwright 实例。同一节还有一条只影响 Windows 的说明：Playwright 在子进程里跑 driver，因此在 Windows 上需要 asyncio 的 ProactorEventLoop，SelectorEventLoop 不支持异步子进程。如果你在 Windows 上手工设过事件循环策略，这条会直接决定你的脚本能不能起来。
顺带一提，Python 侧文档给的是同步与异步两套 API（playwright.sync_api 与 playwright.async_api，见 docs/src/library-python.md，同一页的示例成对给出），docs/src/intro-python.md 开头也写明库本身「for both sync and async Python」。同一段逻辑在这两套 API 下写法不同，这是从别的语言的示例平移过来时最容易抄错的地方。
从处境倒推到结论
- 你要的是「开箱即用的测试工程能力」——并行、重试、分片、HTML 报告、UI Mode、视觉快照、组件测试。这些能力的文档全部在
-js后缀的文件里，test-api/的类也全标langs: js。选别的语言不是不行，是这一层要用该语言生态里的工具自己搭。 - 你要的是「把浏览器自动化嵌进已有的测试工程」。Java 与 .NET 的文档就是按这个前提写的：Java 让你接 JUnit/TestNG，.NET 给你四种运行器的基类。这时候 JS 侧那些运行器特性对你没有意义，你本来也要用团队既有的报告和调度。
- 你在 Python 生态里，且已经在用 Pytest。Pytest 插件补齐了上下文隔离、多浏览器配置、
--tracing/--video/--screenshot这些开关，并行交给pytest-xdist。缺的是 UI Mode 和组件测试。 - 不管哪种语言，你都拿得到：
Locator那一套定位与可操作性、BrowserContext隔离、网络拦截、trace 录制与查看、codegen 与 CLI。
有几个维度我没有比：各绑定的发布节奏、各语言 API 覆盖的完整程度是否有滞后、运行表现——这些我们在仓库文档里没有找到成体系的说明，也没有跑过任何代码，所以不比。同样，本文只对着文档里的 langs 标记与文件后缀说「有没有」，不对四种绑定做优劣排序。
最后提醒一句边界：Playwright 会启动真实浏览器、执行页面脚本、读写存储状态，语言绑定的差异不改变这一点，认证态与 trace 产物里可能带着敏感信息，四种语言都一样需要当心。而这些语言标记本身也随版本调整，写死在你的技术选型文档里之前，最好回到对应的 docs/src/api/class-*.md 里再核一遍当前标记。
本文依据 github.com/microsoft/playwright 仓库于 2026-08-18 的公开内容整理，
事实来自仓库内的文档与源码。我们没有对文中涉及的功能做过实测，
因此不涉及运行速度、稳定性与实际表现的任何描述。
该项目迭代频繁，文中涉及的 API 签名、配置项与默认值随版本变动，请以仓库最新内容为准。
本文不涉及浏览器版本矩阵与版本清单，相关信息请以官方发布说明为准。
本文对照的是同一项目内的多种语言绑定，依据均为上述仓库内容，不对这些绑定做优劣排名， 选型结论只在仓库文档写明的能力边界内成立。
安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。