不少站点的内容更新是掐点进行的：编辑提前写好，设一个发布时间，到点自动放出来。这套机制平时很省事，但一旦时间算错，就会出现两种尴尬——文章提前露出，或者到了点却迟迟不出现。前者可能让未定稿的内容先被访客和蜘蛛看到，后者直接打乱栏目的更新节奏，也让当天的抓取机会白白溜走。
一、最常见的坑：几层时区不一样
后台里的发布时间通常按服务器时区保存，而编辑在浏览器里看到的是本地时间。如果服务器跑在 UTC，编辑在东八区，心里想着上午九点发，实际写进去的可能是凌晨一点。差八个小时，对一篇当天要推的文章来说就是完全不同的曝光窗口。
- 确认服务器时区：系统命令和部署配置里的时区选项，要指向同一个值。
- 确认应用时区：不少框架默认使用 UTC，需要在配置文件里显式改成业务所在时区。
- 确认数据库时区：MySQL 的 time_zone、PostgreSQL 的 timezone，与上面两者不一致时最容易出问题。
- 确认编辑器界面：后台展示的时间是否做了偏移转换，最好在草稿上实测一次。
二、定时任务是否真的跑了
定时发布一般靠 cron、队列或计划任务触发。任务没跑、跑到一半失败、被重复执行，都会让内容状态变得混乱。
- 任务日志里有没有这一次的执行记录，失败原因写的是什么。
- 任务是否被多台机器同时执行，导致同一篇内容被重复发布或状态互相覆盖。
- 队列积压时，实际发布时间会整体后移，需要确认到底晚了多久。
三、内容出来了，页面却没变
发布时间正确，也不代表访客马上能看到新内容，中间还隔着缓存这一层。
- 页面级缓存：应用缓存或反向代理缓存是否设置了 TTL，到点后能否自动失效。
- CDN 边缘节点：有没有把 HTML 也缓存下来，缓存键是否忽略了与发布相关的参数。
- 静态生成：静态页面是否在发布时重新构建并上传，构建任务失败了有没有告警。
- 浏览器缓存：前台是否给 HTML 设置了较长的缓存时间，导致用户本地长时间拿到旧版本。
内容更新后需要刷新几次才看到，是最容易被忽略的信号，通常说明缓存层级比想象中更多。
四、上线前后可以做的自查
- 用一篇不重要的测试内容走完整的定时发布流程，记录实际可见的时间点。
- 对比服务器时间、数据库时间和后台显示时间三者的差值，差值不为零就先修配置。
- 检查定时任务的执行日志，确认失败时会告警，而不是静默跳过。
- 发布后在无痕窗口和不同网络环境下各访问一次，排除本地缓存的干扰。
- 确认新页面能被列表页或内链指到，否则蜘蛛依然需要更久才能发现它。
- 对已发布但时间写错的文章，及时修正发布时间，并检查有没有残留的草稿副本。
五、按顺序排查更省事
遇到该出现却没出现的情况，建议按从内向外的顺序查：先看内容状态是不是已发布，再看数据库里的时间字段，然后看定时任务日志，最后才去查缓存和 CDN。反过来查很容易在缓存上绕半天，其实问题出在任务根本没被触发。
发布时间这类细节平时几乎无感，出问题时又很难一眼看穿。把时区、任务、缓存三件事各自确认一遍，多数到点不上线的情况都能定位到具体环节，剩下的只是修配置和补一次发布。