恢复失效的浏览器配置文件锁
浏览器配置文件锁可以防止两个 Worker 同时打开同一个账号。
大多数自动化系统在恢复过程中都会失败。当 Worker 崩溃或网络中断时，系统会检测到一个旧锁并将其删除。这虽然能让队列继续推进，但会损坏你的账号状态。
失效的锁并不是一个可以简单删除的文件。它是一个需要受控恢复路径的未完成操作。
不要再把锁仅仅视为简单文件。要把它们视为“租约”（Leases）。
一个安全的租约需要：
- 一个所有者 (An owner)
- 一个过期时间 (An expiry time)
- 一个心跳 (A heartbeat)
- 一个版本号 (Fencing token)
版本号至关重要。每次写入都必须包含最新的令牌。如果旧的 Worker 在新的 Worker 接管后返回，系统会拒绝旧的令牌。这可以防止静默损坏。
不要直接从“锁定”跳转到“可用”。使用状态机来经历以下阶段：
- 已持有 (Held)
- 疑似失效 (Suspected stale)
- 已隔离 (Quarantined)
- 已检查 (Inspected)
- 可用 | 等待恢复 | 人工审核 (Available | Resume pending | Manual review)
隔离阶段至关重要。它能防止你在调查期间第二个 Worker 触碰该配置文件。
在调查期间，你必须收集证据：
- 浏览器进程是否仍在运行？
- 上次已知的 URL 是什么？
- 任务是否处于敏感步骤（如结账或设置更改）？
- 是否有失败时的截图？
如果任务在敏感操作期间停止，不要自动恢复。将其发送至人工审核。自动化应该有边界，以防止做出错误的决策。
应避免的常见错误：
- 在未检查配置文件安全性时删除锁。
- 未使用隔离令牌 (fencing tokens) 来拒绝旧 Worker 的延迟写入。
- 在没有已知安全检查点的情况下重试表单提交。
- 在恢复过程中更换代理。
目标不是让恢复变得复杂，而是让它变得明确。
锁只是一个症状。你的系统必须保护锁背后的账号环境。
一个配置文件。 一个所有者租约。 一个活动任务。 一条证据链。 一个恢复决策。