不少站点的内容更新是掐点進行的：編輯提前寫好，设一個發布時間，到点自動放出来。這套机制平时很省事，但一旦時間算错，就會出現两種尴尬——文章提前露出，或者到了点却迟迟不出現。前者可能让未定稿的内容先被訪客和蜘蛛看到，後者直接打乱栏目的更新节奏，也让当天的抓取机會白白溜走。
一、最常见的坑：几层时区不一样
後台里的發布時間通常按服務器时区儲存，而編輯在浏览器里看到的是本地時間。如果服務器跑在 UTC，編輯在東八区，心里想着上午九点發，實际寫進去的可能是凌晨一点。差八個小时，對一篇当天要推的文章来说就是完全不同的曝光窗口。
- 確認服務器时区：系統命令和部署配置里的时区選項，要指向同一個值。
- 確認應用时区：不少框架預設使用 UTC，需要在配置文件里顯式改成业務所在时区。
- 確認資料库时区：MySQL 的 time_zone、PostgreSQL 的 timezone，與上面两者不一致时最容易出問题。
- 確認編輯器界面：後台展示的時間是否做了偏移轉換，最好在草稿上實测一次。
二、定时任務是否真的跑了
定时發布一般靠 cron、队列或計划任務触發。任務没跑、跑到一半失敗、被重复执行，都會让内容狀態變得混乱。
- 任務日誌里有没有這一次的执行记錄，失敗原因寫的是什么。
- 任務是否被多台机器同时执行，導致同一篇内容被重复發布或狀態互相覆盖。
- 队列积压时，實际發布時間會整体後移，需要確認到底晚了多久。
三、内容出来了，頁面却没變
發布時間正确，也不代表訪客马上能看到新内容，中間還隔着缓存這一层。
- 頁面級缓存：應用缓存或反向代理缓存是否設定了 TTL，到点後能否自動失效。
- CDN 邊缘节点：有没有把 HTML 也缓存下来，缓存键是否忽略了與發布相關的參數。
- 静態生成：静態頁面是否在發布时重新构建並上传，构建任務失敗了有没有告警。
- 浏览器缓存：前台是否给 HTML 設定了較長的缓存時間，導致用戶本地長時間拿到舊版本。
内容更新後需要刷新几次才看到，是最容易被忽略的信号，通常說明缓存层級比想象中更多。
四、上线前後可以做的自查
- 用一篇不重要的測試内容走完整的定时發布流程，记錄實际可见的時間点。
- 對比服務器時間、資料库時間和後台顯示時間三者的差值，差值不為零就先修配置。
- 检查定时任務的执行日誌，確認失敗时會告警，而不是静默跳過。
- 發布後在無痕窗口和不同網絡环境下各訪問一次，排除本地缓存的干扰。
- 確認新頁面能被列表頁或内鏈指到，否則蜘蛛依然需要更久才能發現它。
- 對已發布但時間寫错的文章，及时修正發布時間，並检查有没有残留的草稿副本。
五、按顺序排查更省事
遇到该出現却没出現的情况，建议按從内向外的顺序查：先看内容狀態是不是已發布，再看資料库里的時間字段，然後看定时任務日誌，最後才去查缓存和 CDN。反過来查很容易在缓存上绕半天，其實問题出在任務根本没被触發。
發布時間這類细节平时几乎無感，出問题时又很难一眼看穿。把时区、任務、缓存三件事各自確認一遍，多數到点不上线的情况都能定位到具体环节，剩下的只是修配置和补一次發布。