第 11 节：定时任务看似成功，为什么小报没有发出去

自动化任务最迷惑人的地方，是它可能看起来成功了。

宝塔计划任务显示正常。

执行时间也对。

日志里没有明显报错。

但飞书群里就是没有收到每日小报。

这类问题很容易让人怀疑自己：是不是看漏了？是不是机器人没问题？是不是飞书延迟？

后来复盘才发现，定时任务的“成功”，和消息真的送达，是两件事。

访问成功不等于业务成功

计划任务本质上只是按时间访问一个地址。

比如每天早上访问：

report.php?token=...

只要这个 URL 有响应，任务系统就可能认为它执行了。

但对蜡笔小账本来说，真正的业务成功不是“访问了这个地址”。

真正的成功是：

读取到账本数据。

生成昨日小报。

通过 webhook 发给飞书。

飞书返回成功。

用户真的在群里收到。

中间任何一步断了，用户看到的结果都是：没收到。

HTTPS 切换会影响旧地址

有一次问题出在地址上。

早期任务里还写着旧 IP 和 http:// 地址。

后来站点切到 https://horu.world，并且开启强制 HTTPS。旧地址再访问，就可能出现 404 或被拦截。

于是任务看起来还在跑，但它访问的已经不是正确入口。

这件事提醒我：上线配置变了以后，所有自动任务都要跟着检查。

不只是用户访问的页面。

还包括：

飞书回调地址。

定时任务地址。

备份任务地址。

文档里写过的旧链接。

只要有一个地方还停在旧地址，就可能出现“手动能用，自动不行”的情况。

token 错了，也可能看起来像成功

定时任务通常会带一个 token。

这个 token 是为了防止别人随便访问 report.php 触发小报。

但如果换过 token，计划任务里的 URL 没同步更新，就会出现另一个问题。

脚本会返回 bad token。

从业务上看，它没有发任何小报。

但从计划任务系统看，它访问了一个 URL，也拿到了响应。

所以它可能仍然显示“执行成功”。

这也是为什么不能只看计划任务状态。

要看脚本内部到底做了什么。

给自动任务加日志

后来我给 report.php 加了执行留痕。

记录什么时候跑了。

用了什么结果。

发了几份小报。

飞书返回了什么。

如果失败，失败在 token、地址、webhook 还是数据读取。

有了日志以后，问题就从“猜”变成“查”。

这一步很朴素，但很重要。

小产品不一定需要复杂监控。

但关键自动任务至少要留一条线索。

先手动验证，再让它自动跑

排查定时任务时，我会先做一件事：

在浏览器里手动打开那条任务 URL。

如果手动打开都不对，那自动肯定不对。

如果手动能发，再临时把定时任务改到几分钟后执行，看它是否真的能在自动环境里发出。

这个方法很笨，但有效。

它能把问题拆成两段：

脚本本身能不能跑。

计划任务能不能按时触发。

拆开以后，就不会在一个黑盒里乱猜。

本节小结

自动化不是设置一次就结束。

定时任务显示成功，只说明它尝试执行过，不代表每日小报真的送到了用户面前。

地址、HTTPS、token、webhook、日志，每一环都要能查。

下一节，我们会继续做公开前的收尾：HTTPS、敏感文件、token 和备份，为什么这些安全地基必须补上。

FAQ

定时任务显示成功，为什么飞书没收到？

计划任务成功只代表访问动作完成，不代表业务链路完成。可能是 token 错、URL 旧、HTTPS 404、webhook 失败或脚本内部跳过。

为什么 HTTPS 切换会影响定时任务？

如果任务仍然访问旧的 http:// 或 IP 地址，在强制 HTTPS 后可能被拦截或返回 404，需要改成正式域名的 HTTPS 地址。

自动任务为什么要加日志？

因为没有日志只能猜。日志能记录执行时间、发送数量和飞书返回，方便定位到底卡在哪一步。

排查定时任务最简单的方法是什么？

先手动打开任务 URL，确认脚本能跑；再临时把计划任务改到几分钟后执行，验证自动触发是否正常。

token 有什么作用？

token 用来防止外部随便触发任务。换 token 后，配置文件和计划任务 URL 必须同步更新。