不少站点把内容排期做得很好，日历上标得清清楚楚，但真正到点之后页面没有出现，或者只出现在部分入口。问题往往不在编辑，而在定时发布这条链路上：从任务调度、服务器时间、队列执行到缓存与静态化，任何一环掉队，内容就会卡在后台。这篇把定时发布当作一次小型发布流程来做自查。
一、先弄清内容是怎么“发出去”的
不同站点的实现差别很大，常见的有几种：
- CMS 内置的定时发布，靠应用自身的调度器轮询；
- 系统级 crontab 调用脚本，按分钟或小时检查待发布内容；
- 消息队列加消费者，任务被投递后由 worker 执行；
- 静态站点生成器，先生成再推送，发布其实是两步。
先确认自己属于哪一种，再决定观察点。否则排查半天，看的可能是完全无关的日志。
二、服务器时间与时区是最常见的坑
“时间是 10:00，页面却是 18:00 才出现”，这类偏差通常来自时区。检查这几项：
- 服务器系统时区是否为 Asia/Shanghai 或业务需要的时区；
- 应用配置里的时区是否与系统一致，PHP、Java、Node 各有自己的默认值；
- 数据库存的是 UTC 还是本地时间，读取时是否做了转换；
- NTP 同步是否正常，时间漂移会让“每分钟跑一次”的任务错位。
建议统一约定：库里存 UTC，展示和排期按站点时区换算，并在后台明确标注时间含义，避免编辑按本地时间填、系统按 UTC 执行。
三、任务执行失败要能看到、能重试
定时任务失败往往没有提示，只有第二天发现内容没上。至少要保证：
- 每次执行留下日志，记录开始时间、处理条数、失败原因；
- 失败任务有重试机制，且重试不会重复发布同一条内容；
- 连续失败达到阈值时发出告警，邮件或群消息都行；
- 后台能看到“待发布 / 已发布 / 发布失败”的状态，并支持手动补发。
队列场景还要注意消费者是否在运行、并发数是否过低、任务是否被积压。确实出现过 worker 停掉几天、任务全堆在队列里，恢复后一次性涌出的情况，反而给服务器带来额外压力。
四、发布成功不等于页面对外可用
内容状态变成“已发布”只是第一步，接下来还要确认对外表现：
- 前台 URL 能正常打开，返回 200，不是登录后才可见；
- 栏目列表、首页、相关推荐是否已刷新，缓存没更新时用户看到的是旧版本；
- 静态化或 CDN 缓存是否已同步，别让旧页面顶替新内容；
- 标题、正文、图片是否完整，模板变量没有漏成空值；
- 站点地图、订阅源等发现通道是否已包含新地址。
这一步可以做成一个发布后的小检查表，批量发布时抽几条核对即可，不必逐条手工验证。
五、排期本身也要有边界
定时发布容易出现的另一类问题是节奏失控：同一时段堆积几十篇，或者深夜集中上线没人跟进。排期时可以注意：
- 同一栏目保持相对稳定的间隔，避免忽多忽少；
- 重要内容放在有人值守的时段，方便发现问题及时处理；
- 临时改期、撤回的内容，同步更新日历和后台状态，别留下“幽灵任务”。
定时发布的价值是把重复操作交给系统，但系统不会替你判断内容质量，也不会自动发现页面对外不可用。把时间同步、任务日志、发布后检查这三件事做扎实，排期才算真正落地。
如果站点经常出现“排期到了但页面没上”，建议先从服务器时间和任务日志查起，这两处往往能直接给出答案。