xdotool、ydotool、dotool 还是 Playwright：哪款自动化工具适合无头服务器？

如果你曾需要脚本在 Linux 机器上替你点击、输入和发帖，那你一定接触过这四个名字：xdotool、ydotool、dotool 和 Playwright。它们从远处看颇为相似，但工作方式却大相径庭。今天，2026年10月20日，这个问题比以往更受关注，因为许多 Linux 桌面现在运行的是 Wayland 而不是较旧的 X11 系统，这改变了哪些工具能够正常工作。

本文分享了我们在为一家小公司的日常社交媒体发帖任务实现自动化过程中所学到的经验。该任务运行在带有私有隐形屏幕的服务器上，每天向多个网站发布一篇文章。我们在这些工具之间做出了抉择，将其中一个步骤从一种工具换成了另一种工具，并测量了相应的开销。

简要结论

对于隐形 X11 屏幕上的任务，请使用 Playwright （当站点是普通网页时），并保留 xdotool 作为后备。ydotool 和 dotool 是针对不同问题而构建的。在 CPU 和内存方面，Playwright 与 xdotool 之间的差异很小。可靠性要重要得多。

各个工具的实际工作原理

xdotool 与 X11 显示服务进行通信。它可以移动鼠标、点击、键入、按键以及按名称查找窗口。它仅将输入发送到你指定的显示服务。它无法感知屏幕内容，因此如果你需要了解屏幕上有什么，必须自行截图。

ydotool 与 dotool 在更底层工作。它们直接写入内核输入设备（称为 uinput），因此其行为如同直接插入整台机器的真实键盘和鼠标。这就是为什么它们能在 Wayland 上运行，而 xdotool 却不行。代价在于它们无法选择特定窗口，并且会将输入发送给真实桌面上当前获得焦点的任何内容。它们通常还需要额外的权限来使用该输入设备。

Playwright 则属于完全不同的类型。它并不模拟鼠标或键盘，而是直接连接到浏览器并控制网页本身。它可以等待按钮出现、读取输入框中的文本，并在有消息弹出时给出提示。

为什么屏幕类型起到了决定性作用

我们的任务运行在一个私有虚拟显示环境（display）中，这是一个仅存在于内存中的屏幕，因此任何人都无法查看它。这是 X11 环境，所以 xdotool 可以正常工作。而 ydotool 和 dotool 会将输入发送给整台机器，这可能会落到真实的控制台桌面上。在我们的场景中，由于另一位管理员可以看到该桌面屏幕，因此该桌面必须保持锁定状态。所以出于安全考虑而非速度原因，排除了这两种工具。

我们在本次测试中并未运行 ydotool 或 dotool，因此没有关于它们的 CPU 或内存数据。我们所能阐述的均基于它们的工作机制。

步骤 1：找出旧方法的症结所在

我们的首个版本使用了 xdotool 配合屏幕识别（OCR）。它打开待发帖页面，按下按键发送，然后截图并读取文本以查找 "Your post was sent"。

问题出在确认环节。有好几次帖子其实已经成功发布，但脚本却漏掉了该提示并报错 "FAILED"。随后必须由人工手动检查个人主页。这是任何只负责发送输入的工具的主要弱点：它无法确切获知发生了什么，只能通过图片去猜测。

步骤 2：将该步骤迁移至 Playwright

我们通过本地调试端口，将 Playwright 连接到已在私有屏幕上运行的浏览器中。脚本现在会等待撰写框出现，检查我们的文本是否已填入，检查 Post 按钮是否已启用，点击该按钮，然后等待确认。如果错过了提示消息，它会在判定失败之前检查个人主页是否有新发布的帖子。

我们保留了原有的 xdotool 方案作为后备。如果 Playwright 步骤因任何原因失败，系统会发出警告，并改用旧方案进行重试。

步骤 3：测量开销

我们对每种方案进行了一次空跑测试（在最后舍弃帖子），并使用标准的 time 命令进行了测量。

/usr/bin/time -f "wall %es  cpu %U+%Ss  peak RAM %M KB" <command>

	Playwright	xdotool 加 OCR
实际运行时间（Wall time）	9.3 秒	20.2 秒
CPU 时间（用户态加系统态）	1.4 秒	1.1 秒
峰值内存	约 165 MB	约 51 MB

这些是单次测量的结果，并非平均值，因此仅供粗略参考。

Playwright 多使用了约 110 MB 内存，因为它是启动了一个 Node 进程。CPU 消耗几乎相同。Playwright 完成得更快，因为它只需等待页面就绪，而 xdotool 方案使用的是固定等待时间。

最大的开销其实并非来自这两个工具。浏览器本身的所有进程共消耗了约 4.6 GB 内存，而两种方案都要使用它。在这些工具之间做出选择并不会改变这一数字。

步骤 4：依据简单的准则做出决断

1. 如果目标是网页且可以使用浏览器，请使用 Playwright。它能读取页面内容，因此知道发生了什么。
2. 如果你必须在 X11 显示服务上控制非网页内容，请使用 xdotool，并通过读取屏幕来检查结果。
3. 如果你必须控制真实的 Wayland 桌面，请使用 ydotool 或 dotool，并接受输入会发送到整台机器这一事实。
4. 如果网站提供了免费的官方 API，请优先使用 API，而非上述任何工具。

结论

在资源方面，xdotool 节省了约 110 MB 内存，而 CPU 差异微乎其微。在可靠性方面，Playwright 具有压倒性优势，因为它直接检查页面，而不是通过图片去猜测。对于每天运行一次的任务来说，多消耗一秒 CPU 和一点内存并不是真正的成本；迫使人工手动介入检查的“失败”误报才是。

优点

• Playwright 能读取页面内容，因此可以确认操作是否奏效。
• Playwright 不绑定屏幕位置，因此微小的页面布局调整较少会导致其崩溃失效。
• xdotool 非常轻量，除 X11 之外无需安装其他软件。
• xdotool 仅向你指定的显示服务发送输入，从而保证了已锁定桌面的安全性。
• ydotool 和 dotool 可以在 Wayland 上运行，而 xdotool 则不行。
• 保留第二种方案作为后备，意味着单次失败不会中断整个任务。

缺点

• 相比简单的 xdotool 调用，Playwright 占用的内存更多。
• Playwright 依赖页面的元素名称，而网站可能会在不事先通知的情况下更改这些名称。
• xdotool 无法感知屏幕内容，因此需要借助 OCR 或截图，并且可能会误报失败。
• ydotool 和 dotool 会将输入发送给整台机器，无法挑选指定窗口。
• ydotool 和 dotool 通常需要访问内核输入设备的权限。
• 对网站进行浏览器自动化操作可能违反该网站的服务条款，因此请保持较低的操作频率。

注意事项

本文仅供学习参考，介绍的是一种特定配置。文中的数据来自单台机器上的一次空跑测试，在你的机器上可能会有所不同。请将所有占位符替换为你自己的配置，在正式依赖之前检查各工具在你的显示系统下的表现，并查阅你所自动化的任何网站的条款。我们并未测量 ydotool 或 dotool，因此请自行验证它们的开销。

常见问题解答

• 在 Linux 服务器上进行自动化，哪种工具最好？ —— 对于网页，选择 Playwright。对于 X11 显示服务上的非网页程序，使用 xdotool。选择取决于你所控制的对象。
• xdotool 能在 Wayland 上运行吗？ —— 不能用于真实的 Wayland 桌面。它需要一个 X11 显示环境，例如虚拟显示环境。
• ydotool 和 dotool 有什么区别？ —— 两者都直接写入内核输入设备，并且都支持 Wayland。它们的主要区别在于输入命令的方式以及设置方法。
• 哪种工具消耗的 CPU 和内存更少？ —— 在我们的测试中，xdotool 少用了约 110 MB 内存，而 CPU 时间几乎相同。
• Playwright 运行更慢吗？ —— 不会。在我们的测试中，它耗时 9.3 秒，而另一种方案为 20.2 秒，这是因为它不依赖固定时长的等待。
• 这些工具可以在没有显示器的情况下运行吗？ —— 可以。像 Xvfb 这样的虚拟显示环境为它们提供了一个仅存在于内存中的屏幕。
• 为什么还要保留后备方案？ —— 网站随时可能更改其页面。备用方案可以在你修复首选方案的同时，让任务顺利完成。
• 在共享桌面上运行这些工具安全吗？ —— 请务必小心。使用内核输入设备的工具会将输入发送到整台机器，因此更推荐使用私有虚拟显示环境。

标签

#automation #linux #playwright #xdotool #ydotool #dotool #wayland #x11 #browserautomation #devops