技术解读
把「每日签到」交给机器：Daily-Bonus 的多站点签到工程实践
项目背景与痛点
签到脚本这个品类看起来很小，却精准命中了一处很实际的矛盾：不少社区把「每日签到」设计成活跃度指标，用户为了维持等级、积分、铜币或下载额度，不得不每天打开五六个站点重复点击。这件事本身不产生任何信息增量，却长期占用注意力。
Daily-Bonus 解决的并不是单个站点的自动化，而是把散落在不同认证方式、不同接口形态下的签到行为收拢进同一个执行单元：赛马娘网页签到、V2EX、Bilibili、百合会、Yurifans、哔咔漫画。它们的共性是：都依赖登录态（Cookie / Token），都以「每日一次」为幂等单位，都能用一次 HTTP 请求完成；差异在于接口形态——有的是标准 REST API，有的需要解析 HTML 页面，有的要模拟 App 请求体。
真正难的地方在运维面：GitHub Actions 的 cron 是「尽力而为」，高峰期可能延迟甚至跳过；公共仓库的 workflow 在长期无提交后会被自动禁用；Secrets 里的 Cookie 会静默过期。这些构成了典型的「看起来跑通了，其实早就失败了」场景。所以这个项目的工程重点不在签到请求本身，而在可观测性与失效告警。
核心技术揭秘
整体上，它是一个轻量的任务编排器 + 一组站点适配器。分层大致为：入口层（Actions workflow 触发主函数）、配置层（从环境变量/Secrets 注入凭据）、适配层（每站点一个 handler）、结果层（统一收集成败并推送通知）。
几个值得注意的设计取向：
凭据与代码彻底分离。 所有 Cookie、Token 走环境变量注入，仓库里不留明文。这是这类脚本能被公开分享的前提，也决定了它必须依赖 CI 的 Secrets 部署，而不是本地配置文件。
以「站点」为粒度的插件化。 每个站点的签到逻辑相互独立，新增站点只需加一个 handler 并在调度处注册，主流程不感知具体协议。这种写法牺牲了一点抽象的优雅，换来的是极高的可读性和极低的贡献门槛——对社区项目而言，这是正确的取舍。
结果聚合而非逐条报错。 单站点失败不该中断整轮执行，合理做法是统一捕获异常、记录状态码与返回文案，最后汇总成一条通知。你在手机上看到的应是「6 个站点中 4 成功、2 失败（Cookie 过期）」，而不是一片刷屏日志。
幂等与重试的边界。 签到大多是写操作，重复调用可能触发风控或返回「今日已签到」。正确策略是：业务层返回「已签到」即视为成功，不做盲目重试；网络层超时可做有限次重试，业务层失败则直接放弃。
功能亮点与差异
零基础设施。 不需要服务器、不需要常驻进程，Fork 后配置 Secrets 即可运行，边际成本近乎为零。这是相对「自建 crontab + 云主机」方案最直接的优势。
覆盖面有取舍。 它没有追求「支持几百个站点」，而是集中服务 ACG 与中文技术社区这一垂直圈层。接口适配质量，比数量更重要。
通知闭环。 签到脚本的价值不在于跑，而在于「跑失败了你知道」。把结果推送到即时通讯渠道，是把后台脚本升级为可运维系统的关键一步。
应用场景与落地建议
适合个人自用，不适合批量账号或任何形式的代签服务——那会直接踩到站点风控与用户协议。
落地注意四点：其一，仓库务必设为私有，公共仓库的 Actions 有活动度限制，且 workflow 日志对所有人可见，凭据暴露风险更高；其二，Cookie 有效期通常以周或月计，应配合通知做失效提醒，别等积分断了才发现；其三，cron 表达式留出冗余，别把执行时刻压在站点结算的临界点上；其四，访问频率要克制，同一出口 IP 短时间内打多个站点，容易被判为异常流量。
综合评价
优点清晰：结构扁平、易读易改、部署成本为零，覆盖了中文开发者日常高频的几个站点。它是一个「够用且好用」的工具，而不是一个平台。
局限同样明显：缺少统一的接口契约抽象，新增站点仍靠人工读接口；没有凭据自动续期能力，Cookie 过期只能靠人；对风控的应对是消极的（低频、固定 UA），站点一旦改版或加验证码，脚本随即失效；依赖 GitHub Actions 也意味着受制于第三方调度。
一句话总结：这是一份务实的自动化清单，用最小的工程复杂度换取稳定的日常收益。把它当作可维护的个人工具，而不是生产级系统，预期就对了。
相关仓库
学习如何设计大规模系统。为系统设计面试做准备。包含 Anki 闪卡。
![dependabot[bot]](https://avatars.githubusercontent.com/in/29110?v=4)
评论