Playwright结合stealth插件的Firefox示例通过Java调用无法正常结束

1. 优先排查puppeteer-extra-plugin-stealth的兼容性问题 #

puppeteer-extra-plugin-stealth本质是为Chromium内核的Puppeteer设计的，Playwright的Firefox实现与Puppeteer的API、内核机制存在差异，插件可能无法正确适配Firefox，进而导致浏览器进程异常启动、页面加载阻塞。

测试步骤：
临时移除stealth插件，简化Node脚本为纯Playwright启动Firefox的代码：

const { firefox } = require('playwright-extra');

(async () => {
  const browser = await firefox.launch({ headless: true });
  const page = await browser.newPage();
  console.log('页面初始化完成');
  await page.goto('https://bot.sannysoft.com', { waitUntil: 'networkidle' });
  console.log('页面加载完成');
  await browser.close();
})();

如果此时Java调用能正常执行，说明问题根源在stealth插件的兼容性。这种情况下，要么放弃在Firefox上使用该插件，要么手动添加Firefox专用的反检测配置，而非依赖现成插件。

2. 检查是否重复初始化浏览器进程 #

Java调用Node脚本时，可能因为脚本逻辑或Java进程的执行上下文问题，导致browser.launch()被触发两次：

• 在Node脚本中添加日志，打印浏览器启动的时间戳，确认是否存在重复调用：

  console.log(`准备启动Firefox: ${new Date().toISOString()}`);
  const browser = await firefox.launch({ headless: true });
  

• 检查Java代码中是否多次启动了Node子进程，或者是否存在脚本重复执行的逻辑。

3. 调整page.goto的waitUntil参数 #

Firefox对networkidle的判定逻辑与Chromium不同，部分页面在Firefox下可能存在持续的后台请求（如轮询、心跳接口），导致networkidle条件永远无法满足，进而卡住进程。

解决方案：
将waitUntil替换为更宽松的条件，比如'domcontentloaded'或'load'：

await page.goto('https://bot.sannysoft.com', { waitUntil: 'domcontentloaded' });

如果必须使用networkidle，可以尝试指定networkidleTimeout参数设置超时时间：

await page.goto('https://bot.sannysoft.com', { 
  waitUntil: 'networkidle',
  networkidleTimeout: 5000 // 5秒超时
});

4. 排查Java调用的环境差异 #

命令行执行与Java调用Node脚本时，环境变量、工作目录、权限可能存在差异：

• 在Node脚本中打印环境变量，对比两种执行方式的差异：

  console.log('环境变量:', process.env);
  

• 确保Java的ProcessBuilder设置了正确的工作目录，并且传递了必要的环境变量（比如PLAYWRIGHT_BROWSERS_PATH，确保Firefox的安装路径正确）。
• 检查Java是否正确读取了Node子进程的stdout和stderr，如果缓冲区被占满，会导致Node脚本阻塞无法继续执行。

5. 检查Firefox的启动参数 #

尝试显式指定Firefox的启动参数，避免默认配置导致的异常：

const browser = await firefox.launch({
  headless: true,
  args: [
    '--no-sandbox',
    '--disable-gpu',
    '--disable-dev-shm-usage'
  ]
});

这些参数可以避免部分环境下的权限或资源限制问题。

内容的提问来源于stack exchange，提问作者chiperortiz