不少站点把内容排期做得很好，日歷上标得清清楚楚，但真正到点之後頁面没有出現，或者只出現在部分入口。問题往往不在編輯，而在定时發布這條鏈路上：從任務調度、服務器時間、队列执行到缓存與静態化，任何一环掉队，内容就會卡在後台。這篇把定时發布当作一次小型發布流程来做自查。
一、先弄清内容是怎么“發出去”的
不同站点的實現差別很大，常见的有几種：
- CMS 内置的定时發布，靠應用自身的調度器轮询；
- 系統級 crontab 調用脚本，按分钟或小时检查待發布内容；
- 消息队列加消費者，任務被投递後由 worker 执行；
- 静態站点生成器，先生成再推送，發布其實是两步。
先確認自己属于哪一種，再决定观察点。否則排查半天，看的可能是完全無關的日誌。
二、服務器時間與时区是最常见的坑
“時間是 10:00，頁面却是 18:00 才出現”，這類偏差通常来自时区。检查這几項：
- 服務器系統时区是否為 Asia/Shanghai 或业務需要的时区；
- 應用配置里的时区是否與系統一致，PHP、Java、Node 各有自己的預設值；
- 資料库存的是 UTC 還是本地時間，讀取时是否做了轉換；
- NTP 同步是否正常，時間漂移會让“每分钟跑一次”的任務错位。
建议统一约定：库里存 UTC，展示和排期按站点时区換算，並在後台明确标注時間含义，避免編輯按本地時間填、系統按 UTC 执行。
三、任務执行失敗要能看到、能重试
定时任務失敗往往没有提示，只有第二天發現内容没上。至少要保證：
- 每次执行留下日誌，记錄開始時間、處理條數、失敗原因；
- 失敗任務有重试机制，且重试不會重复發布同一條内容；
- 连續失敗達到阈值时發出告警，邮件或群消息都行；
- 後台能看到“待發布 / 已發布 / 發布失敗”的狀態，並支持手動补發。
队列场景還要注意消費者是否在執行、並發數是否過低、任務是否被积压。确實出現過 worker 停掉几天、任務全堆在队列里，恢复後一次性涌出的情况，反而给服務器带来額外压力。
四、發布成功不等于頁面對外可用
内容狀態變成“已發布”只是第一步，接下来還要確認對外表現：
- 前台 URL 能正常打開，返回 200，不是登入後才可见；
- 栏目列表、首頁、相關推荐是否已刷新，缓存没更新时用戶看到的是舊版本；
- 静態化或 CDN 缓存是否已同步，別让舊頁面顶替新内容；
- 标题、正文、图片是否完整，模板變量没有漏成空值；
- 站点地图、订阅源等發現通道是否已包含新地址。
這一步可以做成一個發布後的小检查表，批量發布时抽几條核對即可，不必逐條手工驗證。
五、排期本身也要有邊界
定时發布容易出現的另一類問题是节奏失控：同一时段堆积几十篇，或者深夜集中上线没人跟進。排期时可以注意：
- 同一栏目保持相對稳定的間隔，避免忽多忽少；
- 重要内容放在有人值守的时段，方便發現問题及时處理；
- 临时改期、撤回的内容，同步更新日歷和後台狀態，別留下“幽灵任務”。
定时發布的價值是把重复操作交给系統，但系統不會替你判断内容质量，也不會自動發現頁面對外不可用。把時間同步、任務日誌、發布後检查這三件事做扎實，排期才算真正落地。
如果站点经常出現“排期到了但頁面没上”，建议先從服務器時間和任務日誌查起，這两處往往能直接给出答案。