Douyin Playwright CLI：用 GitHub Actions 每天 00:01 自动跑（不占本地电脑）

TL;DR

• 能做：GitHub Actions 支持 schedule（cron/UTC）+ workflow_dispatch，可以每天自动触发你的 Playwright CLI。
• 核心难点：抖音类站点登录态（storageState.json）与风控（验证码/二次验证/数据中心 IP）。
• 推荐路线：先上 GitHub Actions（最快落地）；不稳定就迁到 self-hosted runner（固定机器/网络 + 可持久化 profile）。

世界上最懂的人会怎么说

Playwright 核心团队视角（工具可靠性）

• 把“登录”与“自动化任务”分开：登录一次导出 storageState，跑任务时只读它。
• CI 里优先可观测性：失败时自动产出 trace/har/screenshot，避免“黑箱”。
• 遇到反爬/风控时，不要硬刚 selector：优先缩小行为差异（headed、稳定等待、减少并发、真实节奏）。

GitHub Actions 架构师视角（调度与运行模型）

• schedule 不是“准点闹钟”：会有排队延迟；正确心态是“每天跑一次”而不是“毫秒级准时”。
• 托管 runner 是一次性环境：任何状态要么写回仓库、要么进 artifact、要么放外部存储。
• Secret 注入是正道：把登录态 base64 放进 Actions Secrets，运行时写回目标路径。

风控/反滥用工程师视角（稳定性边界）

• 数据中心 IP + 自动化浏览器是高风险组合；即使 Playwright “技术上能跑”，也可能因为策略而不稳定。
• “最稳”通常是固定环境：同一台机器、稳定 IP、持久化 profile；必要时人工定期刷新登录态。
• 要预留降级：失败时不重试风暴，转为通知/人工介入，避免账号风险。

架构图：从 00:01 触发到 Playwright 执行

方案对比：把“跑在云端”拆成 4 种实现

落地步骤（最短路径）

1. 把仓库推到 GitHub（工作流必须在仓库根目录的 .github/workflows/）。
2. 本地登录一次，生成/刷新 3_clone_douyin/tools/douyin-music-playwright/storageState.json（不要提交）。
3. 把登录态写到 GitHub Secrets：DOUYIN_STORAGE_STATE_B64（base64 单行）。
4. 默认每天 00:01（上海时区）自动触发；也可以手动触发并传入 packDir。

运维要点（避免账号风险）

• 失败策略：宁可停机通知，也不要无限重试；避免触发更严风控。
• 可观测性：必要时在首跑开启 --trace/--har，定位 selector 变化还是风控拦截。
• 合规：遵守平台规则与账号安全策略；如果出现验证码/二次验证，优先人工介入刷新登录态。

Closing Summary

把这个 Playwright CLI 迁到 GitHub Actions 完全可行；真正的成败点不在代码，而在“登录态与风控”——一旦 GitHub-hosted runner 因 IP/验证码不稳定，立刻迁到 self-hosted runner 才能长期每天跑。

One next action：把 storageState.json base64 写入 GitHub Secret DOUYIN_STORAGE_STATE_B64，然后在 Actions 手动触发一次验证链路。

相关阅读