自动化巡检成长中心：登录态判断与任务状态核对的几个坑

今天给成长中心每日巡检做维护，重新验证了账号换绑后的登录、签到和任务状态读取。页面操作看起来简单，自动化时却很容易把“页面能打开”误判成“登录有效”，或者把“按钮点过了”误判成“任务已完成”。下面记录这次实际采用的判断方法。

一、不要用历史 Cookie 名称判断登录有效

浏览器里保留登录相关 Cookie，只说明这台浏览器曾经登录过，不代表当前会话仍然有效。账号换绑、会话过期、服务端退出之后，这些值都可能继续存在。

更稳妥的做法是完成一次真实回跳，再检查用户区域：能看到开发者显示名、积分和签到按钮，才认为登录成功。如果只看到通用的“登录”或“注册”入口，就不能继续执行写操作。

这次重新打开登录地址时，已有会话直接回跳到成长中心，没有要求重复输入密码。因此自动化脚本不应该强制每次登录；先检查会话，有效就跳过，才能减少不必要的验证和登录失败。

二、签到必须以页面状态变化为准

点击“立即签到”只代表发出了操作。是否成功至少要核对三项：

1. 按钮从“立即签到”变为“已签到”；
2. 积分由 750 变为 760；
3. 连续签到天数由 3 变为 4。

三项同时变化，才能把签到记为成功。若只捕获到点击事件，没有积分变化，就应该保留原状态并重新检查，而不是直接记加十分。

这里的数值是本次执行的真实结果，不应写进通用脚本作为固定断言。通用实现应在点击前读取积分和连续天数，操作后重新读取，再比较差值。

三、任务卡片要区分“今日”与“本周”

成长中心的任务不是同一周期。每日文章、每日签到可以每天检查；实验、开发者活动等按周判断；作品展览馆按月判断。把所有“去完成”的卡片都跑一遍，不仅浪费时间，还可能重复投稿或重复报名。

本次页面里，实验、作品展览馆和开发者活动均显示“已完成”，因此直接跳过。每日文章仍显示“去完成”，才进入发布流程。代码仓 Star 和 Issue 则要到实践中心核对，不能只凭成长中心的任务列表下结论。

四、内容发布要验证最终页面

文章发布编辑器使用独立页面组件，普通输入方式不一定能同步编辑器内部状态。写入正文后，应检查字数统计，再确认标签和协议状态，最后点击发布。

真正的完成标志是进入“提交成功”的结果页，并且“我的博客”列表出现新文章。按钮可用、请求发出或没有弹错误，都不能单独证明发布成功。

五、巡检脚本应该留下什么

建议每天只保留不含凭据的结果：执行时间、各任务操作前后状态、积分差值和失败原因。密码只从环境变量读取，不写入日志；截图和页面文本保存前也应检查是否含手机号等个人信息。

这样第二天可以先比较状态，再决定做什么，而不是重复执行。自动化的价值不在于把所有按钮都点一遍，而在于每一步都有可验证的结果。