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 才是稳定工具；混在一起跑，它就很容易变成难排查的黑盒。