Linux 无头浏览器自动化：Playwright 部署与稳定性实践

一、为什么在 Linux 上使用无头浏览器

无头浏览器可以在没有图形界面的服务器上执行页面加载、表单交互、截图和数据采集。Playwright 将浏览器控制、等待机制和网络观察封装成统一的 API，适合构建可重复的页面自动化流程。

二、运行时与依赖管理

推荐把 Node.js 运行时、项目依赖和浏览器缓存放在独立目录，避免和系统包互相影响。安装依赖时使用锁文件，确保每次构建得到相同版本。

npm ci
PLAYWRIGHT_BROWSERS_PATH=/opt/app/.cache/ms-playwright npx playwright install chromium

Chromium 依赖若干系统库，可以用 ldd 检查缺失项：

ldd /path/to/chrome-headless-shell | grep "not found"

如果运行环境不允许修改系统包，可以把所需库解压到项目私有目录，并通过 LD_LIBRARY_PATH 指向该目录。需要注意 headless shell 和完整版 Chromium 的依赖差异，两者都应单独启动验证。

三、会话复用与页面校验

对于需要登录的流程，可以保存 storageState，在后续任务中复用浏览器会话。保存前先访问目标页面，确认页面状态，再写入认证文件。

const context = await browser.newContext({
  storageState: "storage/auth.json",
  locale: "zh-CN"
});
const page = await context.newPage();
await page.goto("https://example.com/");
console.log(await page.title());

验证登录态时不要只检查 URL，应结合页面上的稳定文本、导航状态或接口返回进行判断；页面结构变化时及时调整选择器。

四、任务编排与可观测性

把一次自动化拆成导航、操作、校验和报告四个阶段。每个阶段设置明确的超时，失败时保留截图、控制台日志和关键页面文本。对列表类任务使用稳定标识，避免依赖容易变化的序号。

执行报告推荐记录任务编号、状态、耗时和失败原因。批量任务应逐项校验结果，部分任务跳过或等待确认时要如实标注，不能把“已尝试”当作“已完成”。

五、单实例与进程回收

定时任务可能重叠执行。可以用文件锁限制单实例，并在退出时清理本次启动的子进程。

exec 9>/opt/app/storage/.daily.lock
flock -n 9 || exit 0

cleanup() {
  kill "$(cat /opt/app/storage/runner.pid)" 2>/dev/null || true
}
trap cleanup EXIT

清理时使用 PID 文件和明确的进程路径，避免按宽泛名称匹配。日志按日期归档，并设置保留周期，便于定位长时间运行中的问题。

六、验证清单

• Node.js 和浏览器版本与主机架构一致
• headless shell 与完整 Chromium 都能启动
• 登录态可复用，页面校验返回真实结果
• 任务报告包含逐项状态和失败原因
• 定时任务只有一个实例，退出后无残留浏览器进程
• 日志、截图和报告写入独立目录

结语

无头浏览器自动化的稳定性来自清晰的运行时边界、可重复的会话管理、明确的超时和可验证的执行结果。把这些工程细节固定下来，才能让自动化从一次性脚本变成可维护的日常工具。