企业官网建设流程全解析

1. 这个项目到底解决了什么问题

做过浏览器自动化的人都有一个共同的痛点：每次让脚本去操作某个网站，都得重新走一遍登录流程。要么手动扫码，要么处理验证码，要么维护一堆cookie文件，过几天就失效了。尤其是那些登录态跟设备指纹绑定的站点，换台机器就得重新折腾。

腾讯开源的 BrowserSkill 这个项目，思路很直接：既然用户本机浏览器里已经有登录好的会话，为什么不让 AI 直接复用这个会话？它做的事情就是在本机浏览器和 AI Agent 之间搭一座桥，让 AI 能够调用你已经登录的浏览器实例来完成任务，而不是从零启动一个干净的、什么登录态都没有的浏览器。

这个项目的核心价值在于三点。第一，省去重复登录。你平时用的 Chrome 里已经登录了各种账号，AI 直接拿来用就行。第二，降低自动化门槛。以前写浏览器自动化脚本，光处理登录和反爬就要花掉大半时间，现在这部分工作可以跳过。第三，让 AI Agent 真正能干活。大模型再聪明，如果没法操作真实的网页界面，很多任务就只能停留在“告诉你怎么做”的层面，而 BrowserSkill 让它能直接“替你做”。

适合谁来参考这个项目？如果你在做 AI Agent 相关的开发，尤其是需要浏览器操作能力的场景，比如自动填表、信息采集、流程自动化、网页测试，这个项目值得仔细看。如果你只是普通用户，想了解 AI 操作浏览器的原理，也能从里面学到不少东西。前端开发者、测试工程师、做 RPA 的同学，都能从中找到有用的部分。

注意：本文讨论的是浏览器自动化技术本身，所有操作均基于本机已授权的浏览器会话，不涉及任何绕过安全机制的行为。

2. 核心架构与设计思路拆解

2.1 为什么是“复用已登录浏览器”而不是“模拟登录”

传统的浏览器自动化方案，比如 Selenium、Puppeteer、Playwright，默认启动的是一个全新的浏览器实例。这个实例没有你的登录态、没有你的书签、没有你的扩展，相当于一张白纸。你要让它访问需要登录的页面，就得自己处理登录流程。

处理登录流程有多麻烦？我列几个常见的坑你就明白了。短信验证码需要人工介入，图形验证码需要接打码平台，有些站点还会检测浏览器指纹，发现你是自动化工具就直接拒绝服务。更别提那些登录态跟设备绑定的场景，换个环境就失效。

BrowserSkill 选择了一条不同的路：它不去模拟登录，而是直接连接到你本机已经打开的浏览器。这个浏览器是你日常使用的，登录态是真实的，指纹是正常的，站点不会把它当成异常访问。AI 通过这个项目提供的接口，向浏览器发送操作指令，浏览器执行完后把结果返回给 AI。

这个设计的好处很明显。登录问题天然解决，因为你用的就是已经登录好的会话。反爬检测的风险大幅降低，因为浏览器指纹跟正常用户完全一致。开发成本也降下来了，不用再写一大堆处理登录的代码。

当然，这个方案也有它的边界。它依赖本机浏览器处于运行状态，如果浏览器没开，AI 就没法操作。它也不适合大规模并发场景，毕竟你本机就一个浏览器实例。所以它更适合个人助手类的应用，而不是大规模采集任务。

2.2 通信机制：AI 和浏览器之间怎么对话

BrowserSkill 的核心是一套通信协议。AI Agent 这边发出指令，比如“打开某个页面”“点击某个按钮”“提取某段文字”，浏览器这边执行动作并返回结果。这套通信机制的设计，直接决定了整个项目的可用性和稳定性。

从项目结构来看，它采用的是本地服务加浏览器扩展的组合方式。本地服务负责接收 AI 的指令，浏览器扩展负责在页面里执行具体操作。两者之间通过本地端口通信，不经过外部网络，数据安全性有保障。

为什么用扩展而不是直接注入脚本？因为扩展有更高的权限，能访问更多的浏览器 API，而且安装一次就能长期使用，不用每次启动都重新注入。扩展还能跨页面工作，在一个标签页里执行完操作，可以切换到另一个标签页继续，这对多步骤任务很重要。

通信协议的设计上，指令和结果都是结构化的数据。指令包含操作类型、目标元素、参数等信息，结果包含执行状态、返回数据、错误信息等。这种结构化设计让 AI 能准确理解浏览器返回的内容，也方便做错误处理和重试。

2.3 与主流方案的对比：优势在哪，局限在哪

把 BrowserSkill 和几种常见方案放在一起对比，能更清楚地看到它的定位。

从表格能看出来，BrowserSkill 在登录态处理和反爬风险这两项上有明显优势，代价是它不适合大规模并发。它的定位很清晰：做 AI 和真实浏览器之间的轻量级桥梁，而不是替代现有的自动化测试框架。

我在实际使用中的体会是，这个方案特别适合那种“一次性、多步骤、需要登录”的任务。比如让 AI 帮你去某个后台系统导出数据，或者去某个平台提交表单。这类任务用传统方案写脚本，光登录就要折腾半天，用 BrowserSkill 就省事很多。

3. 环境准备与安装实操

3.1 前置条件检查清单

在动手之前，先确认你的环境满足以下条件。这些条件缺一不可，少一个都可能导致后面跑不起来。

• 操作系统：Windows 10 及以上、macOS 10.15 及以上、主流 Linux 发行版均可
• 浏览器：Chrome 或基于 Chromium 的浏览器，版本建议 100 以上
• 运行环境：Node.js 16 及以上，或者 Python 3.8 及以上（取决于你用哪种方式集成）
• 网络：本机端口通信正常，没有被安全软件拦截
• 权限：有安装浏览器扩展的权限，有启动本地服务的权限

提示：如果你用的是公司电脑，可能没有安装扩展的权限。这种情况下可以先用个人设备测试，确认方案可行后再考虑如何在受限环境下部署。

检查 Node.js 版本的方法很简单，打开终端输入node -v，看看输出的版本号是否满足要求。如果版本太低，去官网下载最新版安装即可。Python 环境同理，输入python --version查看。

3.2 安装浏览器扩展的完整步骤

浏览器扩展是 BrowserSkill 在页面里执行操作的“手”。安装过程不复杂，但有几个细节容易出错。

第一步，获取扩展文件。从项目的发布页面下载最新的扩展包，通常是一个.crx文件或者一个压缩包。如果是压缩包，先解压到一个固定目录，后面会用到。

第二步，打开 Chrome 的扩展管理页面。在地址栏输入chrome://extensions/回车，或者通过菜单进入“更多工具”然后选择“扩展程序”。

第三步，开启开发者模式。在扩展管理页面右上角，有一个“开发者模式”的开关，把它打开。这一步很关键，不开的话没法加载本地扩展。

第四步，加载扩展。点击“加载已解压的扩展程序”按钮，选择刚才解压的目录。如果下载的是.crx文件，直接拖拽到扩展管理页面也可以安装。

第五步，确认扩展已启用。安装成功后，扩展列表里会出现 BrowserSkill 的图标，确保它是启用状态。建议把它固定到工具栏，方便查看状态。

注意：安装扩展后，建议重启一次浏览器，确保扩展的所有权限都正确加载。我有一次没重启，结果扩展一直连不上本地服务，排查了半天才发现是这个原因。

3.3 启动本地服务的两种方式

本地服务是 AI 和浏览器之间的“翻译官”。它接收 AI 的指令，转换成扩展能理解的消息，再把执行结果返回给 AI。启动方式有两种，根据你的使用场景选择。

方式一：命令行启动。进入项目目录，运行启动命令。这种方式适合开发和调试，能看到详细的日志输出，方便排查问题。

# 进入项目目录 cd browserskill # 安装依赖 npm install # 启动服务 npm start

启动成功后，终端会显示服务监听的端口号，默认是本地回环地址上的某个端口。记住这个端口号，后面配置 AI 端的时候要用。

方式二：作为后台服务运行。如果你希望服务一直运行，不占用终端窗口，可以用进程管理工具把它挂到后台。Linux 和 macOS 下可以用nohup或者pm2，Windows 下可以注册成系统服务。

# 使用 pm2 后台运行 pm2 start npm --name browserskill -- start # 查看运行状态 pm2 status # 查看日志 pm2 logs browserskill

两种方式各有优劣。命令行方式直观，出问题能马上看到；后台方式省心，适合长期运行。我一般开发阶段用命令行，稳定之后切到后台。

3.4 验证安装是否成功

装完之后别急着写复杂逻辑，先做个最简单的验证，确认整条链路是通的。

打开浏览器，随便访问一个页面。然后在终端里调用本地服务的测试接口，看看能不能获取到当前页面的信息。如果返回了页面的标题和 URL，说明 AI 到浏览器的通道已经打通。

# 测试接口，获取当前活动标签页信息 curl http://localhost:端口号/api/current-tab

返回结果应该包含类似这样的内容：

{ "title": "页面标题", "url": "https://当前页面地址", "status": "connected" }

如果返回错误，先检查浏览器扩展是否启用，再检查本地服务是否在运行，最后检查端口号是否对得上。这三个环节任何一个出问题，都会导致连接失败。

4. 核心功能实操与代码示例

4.1 让 AI 读取当前页面内容

读取页面内容是所有操作的基础。AI 要先知道页面上有什么，才能决定下一步做什么。BrowserSkill 提供了获取页面文本、获取特定元素内容、获取页面结构等接口。

获取整个页面的纯文本是最简单的用法。调用接口后，浏览器会把当前页面的可见文本提取出来返回。这个功能适合让 AI 快速了解页面大意，比如判断当前在哪个页面、页面上有哪些主要信息。

// 获取当前页面文本内容 async function getPageContent() { const response = await fetch('http://localhost:端口号/api/page/text'); const data = await response.json(); return data.text; } // 使用示例 const content = await getPageContent(); console.log('页面内容长度:', content.length);

获取特定元素的内容更精准。你可以通过 CSS 选择器指定要提取的元素，比如某个 div、某个表格、某个列表。这种方式适合结构化数据的提取，返回的内容更干净，不需要 AI 再从大段文本里自己找。

// 获取特定元素的内容 async function getElementContent(selector) { const response = await fetch('http://localhost:端口号/api/element/text', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ selector }) }); return await response.json(); } // 提取页面中所有链接 const links = await getElementContent('a');

实操心得：选择器尽量写具体一点。用div.content比用div好，用#main .list li比用li好。选择器越具体，提取的内容越准确，后续处理越省事。

4.2 模拟点击与表单填写

点击和填表是浏览器自动化里最常用的两个操作。BrowserSkill 把这两个操作封装成了简单的接口，AI 只需要告诉它点哪里、填什么就行。

点击操作的接口接收一个选择器参数，找到对应元素后触发点击事件。这里有个细节要注意：有些元素需要先滚动到可视区域才能点击，有些元素被遮挡了需要先处理遮挡。BrowserSkill 内部做了这些处理，但遇到复杂页面时可能还是需要手动干预。

// 点击元素 async function clickElement(selector) { const response = await fetch('http://localhost:端口号/api/element/click', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ selector }) }); return await response.json(); } // 点击登录按钮 await clickElement('#login-btn');

表单填写稍微复杂一点。对于普通的输入框，直接设置 value 就行。但对于一些特殊的输入框，比如 React 或 Vue 控制的组件，直接设 value 可能不生效，需要模拟键盘输入事件。

// 填写表单 async function fillInput(selector, value) { const response = await fetch('http://localhost:端口号/api/element/fill', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ selector, value }) }); return await response.json(); } // 填写搜索框 await fillInput('#search-input', '搜索关键词');

如果遇到直接设 value 不生效的情况，可以改用模拟键盘输入的方式。这种方式更接近真实用户操作，兼容性更好，但速度会慢一些。

// 模拟键盘输入（兼容性更好） async function typeInput(selector, text) { await clickElement(selector); // 先聚焦 for (const char of text) { await fetch('http://localhost:端口号/api/keyboard/type', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ char }) }); } }

4.3 多标签页与多步骤任务编排

真实任务往往不是单步操作，而是多个步骤串起来的。比如“打开后台系统，找到订单页面，导出最近一周的数据”，这里面涉及页面跳转、等待加载、点击按钮、处理下载等多个环节。

BrowserSkill 支持多标签页操作，AI 可以在不同标签页之间切换，也可以在新标签页里打开链接。这对于需要同时处理多个页面的任务很有用。

// 在新标签页打开链接 async function openNewTab(url) { const response = await fetch('http://localhost:端口号/api/tab/new', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ url }) }); return await response.json(); } // 切换标签页 async function switchTab(tabId) { const response = await fetch('http://localhost:端口号/api/tab/switch', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ tabId }) }); return await response.json(); }

多步骤任务的编排，关键是处理好等待和状态检查。页面加载需要时间，元素出现需要时间，操作生效也需要时间。如果不等这些完成就执行下一步，很容易出错。

// 等待元素出现 async function waitForElement(selector, timeout = 10000) { const startTime = Date.now(); while (Date.now() - startTime < timeout) { const response = await fetch('http://localhost:端口号/api/element/exists', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ selector }) }); const data = await response.json(); if (data.exists) return true; await new Promise(r => setTimeout(r, 500)); } throw new Error(`元素 ${selector} 在 ${timeout}ms 内未出现`); } // 多步骤任务示例 async function exportOrderData() { // 第一步：等待订单页面加载 await waitForElement('#order-table'); // 第二步：点击导出按钮 await clickElement('#export-btn'); // 第三步：等待导出完成提示 await waitForElement('.export-success', 30000); console.log('导出完成'); }

注意：等待时间不要设得太短，也不要设得太长。太短容易误判，太长浪费时间。我的经验是，普通元素等待 5 到 10 秒，涉及网络请求的操作等待 30 秒左右，文件下载根据大小适当延长。

4.4 与 AI Agent 的集成方式

BrowserSkill 本身只是一个工具层，真正的价值在于和 AI Agent 结合。AI 负责理解任务、规划步骤、处理异常，BrowserSkill 负责执行具体的浏览器操作。

集成方式有两种。一种是 AI 直接调用 BrowserSkill 的接口，这种方式简单直接，适合任务流程固定的场景。另一种是把 BrowserSkill 封装成 AI 可以调用的工具函数，让 AI 自己决定什么时候调用哪个函数，这种方式更灵活，适合任务流程不固定的场景。

// 把 BrowserSkill 封装成 AI 工具函数 const browserTools = { getPageContent: { description: '获取当前页面的文本内容', parameters: {}, execute: async () => { const response = await fetch('http://localhost:端口号/api/page/text'); return await response.json(); } }, clickElement: { description: '点击页面上的指定元素', parameters: { selector: { type: 'string', description: '元素的 CSS 选择器' } }, execute: async ({ selector }) => { const response = await fetch('http://localhost:端口号/api/element/click', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ selector }) }); return await response.json(); } } }; // AI 调用示例 async function aiAgentTask(taskDescription) { // 把工具描述传给 AI，让 AI 决定调用哪个工具 const toolsDescription = Object.entries(browserTools).map(([name, tool]) => ({ name, description: tool.description, parameters: tool.parameters })); // AI 返回要调用的工具和参数 const aiDecision = await callAI(taskDescription, toolsDescription); // 执行 AI 决定的工具调用 const tool = browserTools[aiDecision.name]; const result = await tool.execute(aiDecision.parameters); return result; }

这种集成方式的好处是，AI 可以根据页面内容动态决定下一步操作。比如它发现页面上有“下一页”按钮，就会自动点击继续翻页；发现需要登录，就会提示用户先登录。这种灵活性是固定脚本做不到的。

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

5.1 连接类问题排查

连接类问题是最常见的，表现是 AI 发指令后浏览器没反应，或者返回连接错误。这类问题的排查思路是从下往上查：先确认浏览器扩展是否正常，再确认本地服务是否运行，最后确认两者之间的端口是否对得上。

我遇到最多的情况是端口被占用。本地服务默认用的端口，可能被其他程序占用了，导致服务启动失败但没报错。排查方法是看服务启动日志里有没有“端口已被占用”的提示，有的话换个端口重新启动就行。

还有一种情况是浏览器开了多个用户配置。Chrome 支持多用户，每个用户有独立的扩展和登录态。如果你在用户 A 下装了扩展，但浏览器当前用的是用户 B，扩展就不会生效。解决方法是确认当前使用的用户配置下扩展已安装并启用。

5.2 元素定位失败的处理

元素定位失败是第二类高频问题。表现是接口返回“元素未找到”，但你在页面上明明能看到这个元素。这种情况通常有几个原因。

第一个原因是元素在 iframe 里。iframe 是页面里的独立文档，主文档的选择器找不到 iframe 里的元素。解决方法是先切换到对应的 iframe，再执行选择器。

// 切换到 iframe 后再操作 async function switchToIframe(iframeSelector) { await fetch('http://localhost:端口号/api/frame/switch', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ selector: iframeSelector }) }); } // 操作完记得切回主文档 async function switchToMainFrame() { await fetch('http://localhost:端口号/api/frame/main', { method: 'POST' }); }

第二个原因是元素是动态生成的，你查找的时候它还没出现。解决方法是加等待逻辑，等元素出现后再操作。前面讲过的waitForElement就是干这个的。

第三个原因是选择器写错了。CSS 选择器对大小写、空格、特殊字符都很敏感，写错一个字符就找不到。建议在浏览器开发者工具里先验证选择器是否正确，确认能选中目标元素后再写到代码里。

实操心得：开发者工具的 Console 里可以用document.querySelector('你的选择器')快速验证选择器。返回元素说明选择器正确，返回 null 说明选择器有问题。这个方法能省掉大量调试时间。

5.3 操作不生效的排查思路

有时候接口返回成功了，但页面上的操作没生效。比如点击了按钮但页面没跳转，填了内容但提交后是空的。这类问题比较隐蔽，需要仔细排查。

点击不生效的常见原因是元素被遮挡。页面上可能有弹窗、浮层、固定导航栏挡住了目标元素，点击事件被这些遮挡物接收了。解决方法是先关闭遮挡物，或者用脚本方式直接触发元素的点击事件。

// 强制点击（绕过遮挡检测） async function forceClick(selector) { await fetch('http://localhost:端口号/api/element/click', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ selector, force: true }) }); }

填写不生效的常见原因是框架的双向绑定没触发。React、Vue 这类框架，直接设 input 的 value 不会触发框架的更新逻辑，需要手动派发 input 事件。

// 填写并触发框架更新 async function fillWithEvent(selector, value) { await fetch('http://localhost:端口号/api/element/fill', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ selector, value, triggerEvents: ['input', 'change', 'blur'] }) }); }

5.4 性能与稳定性优化建议

用了一段时间之后，你会发现有些操作比较慢，或者偶尔会失败。这时候可以从几个方面做优化。

减少不必要的页面读取。每次读取页面内容都要传输数据，页面大的话传输量不小。如果只需要页面上某个区域的内容，就用元素选择器精确提取，不要每次都读整个页面。

合理设置等待时间。等待时间太短容易失败，太长浪费时间。可以根据操作类型设置不同的等待时间，普通元素 5 秒，网络请求 30 秒，文件下载 60 秒。还可以用轮询代替固定等待，元素一出现就继续，不用等满整个超时时间。

做好错误重试。网络波动、页面加载慢、元素暂时不可见，这些都可能造成偶发失败。给关键操作加上重试逻辑，失败后等一秒再试，试三次还失败才报错。这样能大幅提升整体成功率。

// 带重试的操作封装 async function withRetry(fn, maxRetries = 3, delay = 1000) { for (let i = 0; i < maxRetries; i++) { try { return await fn(); } catch (error) { if (i === maxRetries - 1) throw error; console.log(`第 ${i + 1} 次失败，${delay}ms 后重试`); await new Promise(r => setTimeout(r, delay)); } } } // 使用示例 await withRetry(() => clickElement('#submit-btn'));

提示：重试不是万能的。如果是选择器写错这种确定性错误，重试多少次都没用。重试只对偶发性错误有效，比如网络抖动、页面加载慢。排查问题时先区分是确定性错误还是偶发性错误，再决定要不要加重试。

6. 实际应用场景与扩展思路

6.1 适合落地的几类场景

BrowserSkill 最适合的场景，是那种需要登录态、操作步骤多、但不需要高并发的任务。我整理了几类实际用过的场景，供你参考。

后台系统数据导出。很多后台系统需要登录才能访问，导出功能藏在多层菜单里。用 BrowserSkill 可以让 AI 自动登录后的浏览器里完成“进入菜单、选择条件、点击导出、等待完成”这一串操作。相比写固定脚本，AI 能根据页面实际情况灵活调整，比如遇到弹窗能自动关闭，遇到加载慢能自动等待。

跨平台信息汇总。你需要从多个平台收集信息，每个平台都要登录。传统做法是每个平台写一个脚本，维护成本很高。用 BrowserSkill 可以统一在一个浏览器里操作，AI 负责在不同标签页之间切换，把各平台的信息汇总到一起。

网页表单批量填写。有些场景需要重复填写类似的表单，比如报名、登记、申报。AI 可以从结构化数据里读取内容，自动填写到网页表单里，填完一个提交再填下一个。这种任务用 BrowserSkill 做，比人工填快得多，也比固定脚本灵活。

6.2 扩展思路：从单机到协作

BrowserSkill 目前主要解决的是单机场景，就是 AI 操作本机浏览器。如果把这个思路扩展一下，还能做更多事情。

多浏览器实例管理。如果你需要同时操作多个浏览器窗口，可以启动多个浏览器实例，每个实例装一个扩展，本地服务负责协调它们之间的操作。这样能实现一定程度的并行，适合需要同时处理多个任务的场景。

操作录制与回放。把 AI 的操作过程记录下来，形成操作序列。下次遇到类似任务，可以直接回放这个序列，不用再让 AI 重新规划。这种方式结合了 AI 的灵活性和脚本的可重复性，是个不错的折中方案。

与工作流引擎结合。把 BrowserSkill 作为一个节点接入工作流引擎，前面接数据处理节点，后面接通知节点。这样能构建更复杂的自动化流程，浏览器操作只是其中一环。

6.3 安全与合规使用的边界

用这类工具的时候，有几个边界要特别注意。只操作你自己有权限访问的系统和数据，不要用它去访问未授权的资源。遵守目标网站的使用条款，不要用它做大规模采集或高频请求。保护好本机的登录态，不要在不信任的环境里运行本地服务。

本地服务默认只监听本机回环地址，外部网络访问不到，这是基本的安全保障。如果你修改了配置让它监听外部地址，一定要加上认证机制，否则等于把浏览器控制权开放给了整个网络。

注意：浏览器里保存着你大量的登录态和个人信息。运行任何浏览器自动化工具之前，确认工具来源可靠，代码经过审查。不要运行来路不明的扩展或服务，这是保护自己的基本操作。

7. 我踩过的几个坑和对应解法

第一个坑是扩展版本和服务版本不匹配。项目更新比较快，扩展和服务如果版本差太多，通信协议可能对不上，表现是连接成功但指令执行失败。解决方法是扩展和服务用同一个版本，更新的时候一起更新。

第二个坑是浏览器开了硬件加速导致截图异常。有些操作需要截图确认结果，如果浏览器开了硬件加速，截图可能是黑屏或者花屏。解决方法是关掉硬件加速，或者在截图前先禁用相关选项。

第三个坑是页面有多个相同选择器的元素。比如页面上有多个“提交”按钮，选择器#submit只能选中第一个，但你要点的是第二个。解决方法是把选择器写得更具体，加上父级元素的限定，或者用索引指定第几个。

第四个坑是操作太快导致状态不同步。连续执行多个操作时，如果不等前一个操作生效就执行下一个，很容易出错。比如点击“编辑”按钮后立即填写表单，但编辑页面还没加载出来。解决方法是在关键操作之间加等待，等页面状态稳定后再继续。

第五个坑是忘记处理浏览器弹窗。原生的 alert、confirm、prompt 弹窗会阻塞页面操作，如果不处理，后续操作都会卡住。解决方法是监听弹窗事件，自动确认或取消，或者在操作前先检查有没有弹窗。

// 自动处理弹窗 async function handleDialogs() { await fetch('http://localhost:端口号/api/dialog/auto', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ action: 'accept' }) // 自动确认 }); }

这几个坑都是我实际踩过的，每个都花了不少时间排查。写出来希望能帮你少走弯路。浏览器自动化这个领域，细节特别多，同一个问题可能有多种原因，排查的时候要有耐心，从最简单的可能性开始查起。

最后分享一个小技巧：调试的时候把本地服务的日志级别调到最详细，每个指令的发送和返回都打出来。这样出问题的时候能快速定位是哪个环节出的错。等稳定运行之后再把日志级别调回去，避免日志太多影响性能。