定时发布的时间带了时区差，前台排序和推送会怎么乱

定时发布靠的是一个时间因子：设定内容在某个时间点从「待发布」转为「正式」。当这个时间带了时区差，问题不会停在「晚了几小时上线」，而是会串到前台排序和链接推送两处——上线时刻整体偏移，排序错位、推送时机也跟着错。要理清，先分清内容状态，再对齐时区口径。

时间因子管的是哪一段

时间因子管的是「内容什么时候对外可见」这一段。定时发布让一篇文章不立即上线，而是等设定的发布时间到达后转为正式可见。它不改变内容本身，只改变它进入正式状态的时刻。正因为只动这一个时刻，一旦这个时刻的时区理解有偏差，偏移就会往下游传：下游的排序和推送都以「什么时候算正式」为触发点。

状态流转与可见范围

要理解时区差影响在哪，得先看清文档状态怎么流转。文档分为正式文档、草稿、待发布和回收站几种状态：草稿是编辑中的版本，其预览链接带 preview=true 只在预览时可见；待发布是已经设定了将来某个发布时间、还没到点的状态；到点后转为正式，才会被前台列表和搜索引擎看到。删除正式文档是移入回收站而非物理删除，需要时可恢复。时区偏差真正扰乱的是「待发布→正式」这个转换点：转换点前，内容不该进推送队列；转换点后，才进入前台排序与推送的范围。

时区偏差的两种表现

第一种表现是排序错位。前台列表多按时间排序，如果服务器与设定发布时间所处的时区不一致，本应排在前面的新内容会因为时间标签偏早或偏晚而错位，尤其是把「按入库时间」和「按发布时间」两套口径混用时更明显。第二种表现是推送时机不对。链接推送、主动推送是给加速收录用的，向搜索引擎推送新内容；待发布内容在未到点前不应被推送，但如果系统按错误的时区判断「已经到点」，就可能把还没正式上线的内容推出去，或把已上线的漏推。两种表现的根子都是同一个：上线时刻的时区口径没对齐。

上线前的核对动作

上线前把口径统一：确认服务器时区与站点展示时区是否一致，确认列表排序到底以入库时间还是发布时间为准，并把这个规则固定下来，别一会儿用这个一会儿用那个。定时发布前，先核对该篇设定的发布时间在当前时区下对应的是不是想要的那个点。执行备份恢复时，要把发布时间一起核对——备份覆盖数据与静态文件，恢复后若发布时间随环境时区发生偏移，排序和推送会再次错乱，所以恢复动作里要包含一次上线状态与推送队列的检查，而不是只看内容在不在。

常见问题

问：待发布的内容会被推送给搜索引擎吗？ 答：正常不应推送，只有转为正式后才进入链接推送的范围。

问：排序到底按入库时间还是发布时间？ 答：要定一个口径并固定，混用正是时区差把排序搞乱的地方。

问：恢复备份后要额外看什么？ 答：连发布时间一起核对，确认时区没让上线时刻偏移。