Headless 浏览器自动化适合哪些任务？巡检、截图和提交动作要分级

Headless 浏览器自动化很适合做重复、低干预、可验证的任务，但不适合一上来就接所有页面操作。

很多任务失败，不是 Headless 本身有问题，而是把任务风险混在了一起：页面巡检、截图留证、数据读取、表单预填、正式提交，全都按同一套脚本跑。这样一旦页面状态变化，很难判断该重试、暂停还是交给人工处理。

更稳的做法，是先按动作风险分级。

1. 适合 Headless 的低风险任务

第一类是只读型任务。

常见场景包括：

检查页面是否打开；
读取 HTTP 状态码；
等待关键元素出现；
截图保存页面状态；
导出页面标题、URL、时间戳和关键字段；
对失败页面做日志归档。

这类任务的特点是：即使失败，也不会改变账号或业务状态。

排查时可以记录：

复制代码

task_id: daily_page_check
profile_id: shop-us-01
url: target_page
status_code: 200
selector: #main
screenshot: saved
timeout_ms: 15000
result: pass / fail / timeout

注意，状态码成功不等于页面可用。页面可能返回成功状态，但关键元素没出来，也可能被重定向到登录页。所以至少要同时看状态码、URL、关键元素和截图。

2. 中风险任务要加停止点

第二类是会进入账号环境，但还不直接提交结果的任务。

比如：

打开后台页面；
切换筛选条件；
读取任务列表；
预填表单；
生成草稿；
汇总待复核字段。

这类任务可以自动化，但要设置停止点。

停止点不是报错才停，而是遇到状态不确定就停。例如：

复制代码

stop_when:
- 当前 URL 和预期页面不一致
- 出现二次验证页面
- 关键按钮文案变化
- 表单字段缺失
- 读取到空数据但截图显示页面正常
- 账号状态提示异常

中风险任务的目标不是"一路跑完"，而是把可重复部分跑完，把需要判断的部分留下证据。

3. 高风险提交动作不要和巡检混跑

第三类是会改变业务结果的动作。

例如正式提交、发布、删除、修改状态、确认付款、批量变更设置等。

这些动作不适合和页面巡检脚本混在一起。即使要自动化，也应该单独建任务，明确输入、前置条件、复核证据和人工确认点。

一个简单规则是：

复制代码

read_only: 可以自动重试
prepare_only: 可以自动预填，但需要复核
write_action: 不自动重试，先保留证据

这样做的好处是，失败时不会出现"脚本到底有没有点过提交"的问题。

4. Headless 任务至少保留四类证据

如果团队里有人要接手排查，光有脚本输出是不够的。

建议每次任务至少留下：

运行环境：Profile、代理、语言、时区；
页面状态：URL、状态码、关键元素、重定向情况；
执行证据：截图、Trace、步骤名、耗时；
处理结论：成功、超时、可重试、待人工复核。

如果这些证据散在脚本日志、截图文件夹和聊天记录里，排查会很慢。更好的方式是让页面状态、截图、日志和人工复核证据能对应到同一次任务记录里，开发和运营看到的是同一个现场。

5. 排查顺序

遇到 Headless 任务失败，可以按这个顺序看：

先看是否进入了正确 Profile；
再看代理、语言、时区是否符合任务要求；
再看 URL 是否被重定向；
再看关键元素是否存在；
再看截图和 Trace 是否能解释页面状态；
最后判断是重试、暂停还是交给人工复核。

不要一失败就重跑。重跑会覆盖现场，也可能把一次可解释的问题变成多次混乱记录。

结论

Headless 浏览器自动化适合低风险、可重复、可留证的任务。

页面巡检、截图、字段读取和日志归档可以优先自动化；预填和草稿生成要加停止点；正式提交、删除和批量修改这类动作要单独设计复核流程。

把动作风险分清楚，Headless 才是稳定工具；混在一起跑，它就很容易变成难排查的黑盒。