定时任务失败先别改代码：证明面板跑的是哪一份副本

现象很有迷惑性：脚本在开发目录里跑通，面板里 07:35 的定时却报登录态失效。第一反应是站点风控、Cookie 过期、环境变量没注入，逐个排下来全不对。真实原因朴素得让人尴尬——面板执行的是另一份拷贝，而那次改动只同步了开发目录。

一、先确认是不是双副本

import hashlib, os
def md5(p):
    return hashlib.md5(open(p, "rb").read()).hexdigest()[:12]

dev, panel = r"<开发目录>", r"<面板脚本目录>"
for name in ("每日任务.py", "登录工具.py"):
    a, b = os.path.join(dev, name), os.path.join(panel, name)
    print("%-14s %s %s %s" % (name, md5(a), md5(b), "SAME" if md5(a) == md5(b) else "DIFF"))

DIFF 就说明是两份独立文件（不是软链接），任何「改完就好」的判断都必须以面板目录为准。这一步要写成脚本跑，别靠肉眼比时间戳——同步失败与同步成功的时间差可能只有几秒。

二、用面板目录复现，才算验证

cd <面板脚本目录>
python -u 每日任务.py

之所以等价：脚本用 __file__ 同级目录做 import，Cookie 与状态文件全是绝对默认值，面板注入的通知函数在本地缺失时脚本会打印「无推送渠道」并正常结束。反过来说，只要脚本里有「相对当前工作目录」的读写，本地跑通就不能代表面板跑通，这种依赖要顺手改成基于 __file__ 的绝对路径。

三、别指望用 HTTP 触发任务来验证

想通过面板 API 手动跑一次任务，结果发现 Web 端口只 serving 静态单页：POST /cron/run 返回 Express 的 Cannot POST，而 GET /cron、/crons 一律回 HTML 壳而不是 JSON。这种「看着像接口其实是前端路由」的情况，判据很简单——先看响应首字符是不是 {，不是 JSON 就说明打错了主机或打错了端口，别把它解读成鉴权失败。

小结

定时任务排错顺序应该是：先证明跑的是哪份代码（md5），再证明那份代码在当前目录能跑（本地复现），最后才怀疑业务逻辑。跳过前两步会在环境和风控上白白耗掉半天。