一句话结论：可靠的网页批量自动化应该是"先过滤，再按顺序执行"。每项任务都要有独立状态、结果反馈和异常处理，不能简单地同时打开大量页面并模拟点击。
网页上的重复操作，看起来很适合自动化。
假设用户选中了几十笔订单，需要逐一进入对应页面完成相同操作。最直接的想法是遍历订单数组，打开页面，然后点击按钮。
真正做起来，很快会遇到问题：
- 有些订单早已处理；
- 有些订单当前不符合条件；
- 页面加载时间不固定；
- 点击后不一定马上出现结果；
- 中途登录可能失效；
- 用户可能需要暂停或停止；
- 新窗口和原页面之间还要交换状态。
因此，一个可用的批量网页任务，重点不在"能不能点击按钮"，而在于每次点击以后，程序是否知道发生了什么。
批量不等于同时执行
网页自动化最容易犯的错误，是把批量任务写成高并发任务。
如果同时打开大量页面，会带来几个麻烦。页面加载会互相争抢资源，处理结果难以对应到具体订单，网站也可能因为短时间出现大量操作而返回异常。
顺序队列更适合这种场景。
基本流程如下：
取出一个待处理项目
→ 判断是否需要跳过
→ 打开或导航到目标页面
→ 等待页面准备完成
→ 执行操作
→ 获取处理结果
→ 更新当前项目状态
→ 短暂等待
→ 处理下一个项目处理速度未必是理论上最快的，但状态更容易控制。出现问题时，也能知道卡在哪一项。
开始执行前，先过滤无效任务
批量任务不应该接到数据后立即操作。
以订单发票申请为例，列表中可能同时存在尚未申请、已经申请、已经开票、待发货、退款和售后订单。
如果程序不做前置判断，已经处理过的订单也会重复进入页面。即使页面最后拒绝提交，仍然浪费了一次加载和检测。
比较合理的数据结构是：
{
id: "订单标识",
status: "pending",
reason: ""
}状态可以设置为：
pending
processing
success
failed
skipped其中，skipped 不应和 failed 混为一谈。
已经申请过的订单被跳过，是程序做出了正确判断。页面加载失败，则属于执行异常。两者对用户的意义完全不同。
为什么每项任务都要单独记录状态？
如果界面上只有一个总进度条，用户只知道"处理到80%"，不知道剩下的20%发生了什么。
每项任务单独记录后，批量结果才有可追踪性。
例如：
| 状态 | 用户看到的含义 |
|---|---|
| 等待中 | 尚未开始处理 |
| 处理中 | 当前页面正在执行 |
| 已提交 | 操作已经获得成功结果 |
| 已跳过 | 该项目不需要执行 |
| 失败 | 本次操作没有完成 |
任务结束后，用户可以只检查失败项目。
如果没有单项状态，一笔异常就可能迫使用户重新检查整个列表。这种自动化虽然能点击按钮，却没有真正减少人工判断。
复用窗口比不断创建窗口更稳妥
批量操作经常需要进入不同URL。
一种写法是每个任务创建一个新窗口，操作完成后关闭。订单一多，窗口会频繁创建和销毁，用户也会看到页面不断闪动。
另一种做法是创建一个处理窗口，后续任务复用它。每次只更新当前标签页的URL，等待页面操作完成，再导航到下一项。
伪代码可以写成：
const workerWindow = await ensureWorkerWindow();
for (const task of tasks) {
if (task.status === "skipped") continue;
task.status = "processing";
renderTask(task);
const result = await navigateAndWait(
workerWindow,
task.targetUrl
);
task.status = result.success ? "success" : "failed";
task.reason = result.error || "";
renderTask(task);
}窗口复用降低了界面干扰，也方便程序保存当前处理窗口的标识。
需要注意，用户可能在任务中途手动关闭窗口。ensureWorkerWindow() 不能只在任务开始时执行一次，每次导航前都应该确认窗口是否仍然存在。
跨页面结果怎样返回？
订单列表和目标操作页通常不是同一个页面。
原页面负责维护任务队列，目标页面负责寻找按钮、点击并判断结果。两者之间需要一条可靠的通信通道。
在Chrome扩展中，可以使用运行时消息：
chrome.runtime.sendMessage({
action: "task_result",
data: {
id: taskId,
success: true
}
});后台脚本收到消息后，再将结果转发给维护任务状态的页面。
有些实现会使用window.opener.postMessage()。这可以作为兼容方案，但不能把它当作唯一通道。通过浏览器扩展API创建的新窗口不一定保留opener，此时目标页无法通过它找到原页面。
稳定的主通道应该由扩展运行时消息承担。
页面加载成功，不代表业务操作成功
自动化脚本不能看到页面出现就立即返回成功。
它至少要检查这些情况：
- 页面是否显示已经处理；
- 是否出现不支持或无法操作的提示；
- 目标按钮是否存在且可见；
- 点击后是否出现确认步骤；
- 提交后是否出现成功提示；
- 页面状态是否发生了可验证的变化。
如果按钮没有找到，也不能直接判断失败。页面可能已经处理过，只是不再显示申请按钮。
因此，推荐的判断顺序是：
先检查"已处理"或"不支持"状态
→ 再寻找目标按钮
→ 点击并处理确认步骤
→ 监听结果提示或页面状态变化
→ 超时后返回明确错误这里最忌讳的是"点击过就算成功"。
点击只说明事件被触发，不代表网站接受了操作。程序应该尽量寻找能够验证结果的页面信号。
为什么必须设置超时？
目标网站可能一直处于加载状态，也可能因为页面结构变化找不到按钮。
如果没有超时，一笔任务就能卡住整个队列。后面的任务永远不会开始，用户也不知道发生了什么。
每个任务都应有独立超时。超时后将当前项目标记为失败，记录原因，再决定是否继续下一项。
如果错误涉及登录过期，则不适合继续执行。后面的任务即使打开页面，也不会成功。
这时应该：
- 标记当前任务失败；
- 将后续待处理项目标记为停止或跳过；
- 关闭处理窗口；
- 提示用户重新登录；
- 保留已经完成的结果。
登录错误和普通页面错误不能采用同一种恢复策略。
暂停和停止不是只改按钮文字
一个真正可控制的批量任务，需要在每次开始新项目之前检查状态。
暂停时，当前正在执行的项目可以先完成，但不再启动下一项。继续后，从保存的索引接着处理。
停止时，程序应结束循环，关闭处理窗口，并将尚未开始的项目标记出来。
简单的判断可以放在循环开头：
while (index < tasks.length) {
if (state.stopped) break;
if (state.paused) {
state.currentIndex = index;
return;
}
await processTask(tasks[index]);
index += 1;
}如果只是把按钮从"暂停"改成"继续"，但后台循环仍然运行，那不算暂停。
一个实际项目怎样使用这套思路？
多多开票助手中的拼多多批量申请发票采用了类似流程。
用户加载订单后可以直接全选。任务开始前，插件会过滤已经申请、已经开票、待发货、退款和售后订单，再依次处理剩余部分。
执行时复用一个发票窗口。目标页面负责检测订单状态、寻找申请按钮、执行确认并返回结果；助手面板维护任务列表，显示已提交、失败或跳过。
用户可以暂停、继续或停止任务。遇到登录过期时，后续操作会停止，避免在失效状态下继续打开订单页面。
这里的自动化目标很明确：减少买家重复进入页面和点击确认的操作。
发票本身仍由商家开具。插件只能提交申请，不能把"操作已提交"写成"发票已生成"。
这个项目是独立第三方浏览器扩展，与拼多多官方没有隶属关系。项目介绍见 多多开票助手 。
这类批量任务还应该注意什么？
如果准备开发类似功能，可以用下面这份清单做一次自查：
- 每项任务是否有唯一标识；
- 是否区分等待、处理、成功、失败和跳过；
- 执行前是否过滤无需处理的数据；
- 是否采用可控的顺序队列；
- 页面操作结果是否可以验证；
- 是否设置了单项超时；
- 登录失效后是否停止后续任务；
- 用户是否可以暂停和停止；
- 处理窗口被关闭后能否重新创建；
- 已经完成的任务是否会被重复执行。
按钮自动点击并不难。难的是失败以后，程序和用户都清楚下一步应该做什么。
常见问题
网页批量操作为什么不建议同时打开很多页面？
大量页面并发会增加资源消耗，也让处理结果更难与具体任务对应。顺序队列更容易控制状态和异常。
找不到操作按钮时，应该直接返回失败吗？
不一定。页面可能已经处理过，目标按钮因此不再显示。应先检查已处理和不支持状态。
为什么要区分失败和跳过？
失败表示本次操作没有完成，跳过表示该项目无需执行或当前不适合执行。两者后续处理方式不同。
window.opener可以用来传递结果吗？
可以作为备用方式，但不适合作为唯一通道。由扩展API创建的窗口可能没有可用的opener。
批量任务显示成功，是否等于业务已经全部完成？
不一定。成功只代表当前自动化步骤得到了预期结果。后续业务可能仍需要网站、商家或用户继续处理。