服務器上跑着很多和時間有關的東西：日誌记錄、定时任務、缓存過期、證书有效期、内容發布時間。它們各自记着時間，但如果时区設定不统一，這些時間就會互相打架。等到排查問题时，你會發現日誌里的 03:00 到底是凌晨三点還是上午十一点，全凭猜。
时区不一致會带来什么麻烦
日誌時間與真實訪問對不上
訪問日誌預設记錄的通常是服務器本地時間。如果服務器设成 UTC，而你和同事都在東八区看报表，日誌里的高峰时段會整体偏移 8 小时。蜘蛛抓取的時間分布、真人訪客的活動規律，看起来全都错位。做抓取频率分析时，很容易得出“蜘蛛半夜特別活跃”這種其實只是时区错觉的结论。
定时任務在错誤的時間点执行
cron 表達式按系統时区解释。同一份配置搬到新服務器上，如果新机器时区不同，备份、清理、缓存刷新就可能從凌晨挪到白天高峰，抢走本该留给訪客的资源。
缓存與證书的有效期判断出错
應用层缓存、CDN 缓存、Cookie 有效期、HTTPS 證书到期時間，前端展示和後端判断用的时区不一致时，會出現“明明還没過期却提前失效”或者“過期了還在用”的情况。
自查清單
- 確認服務器系統时区：用命令查看目前时区設定，並寫進部署文档，別只靠运维记忆。
- 统一日誌时区：至少在日誌格式里带上时区偏移，或者统一按 UTC 记錄，在报表层再換算。
- 检查應用配置里的时区參數：資料库连接、語言執行时、Web 服務器各有一份时区設定，逐一核對。
- 核對定时任務的實际触發時間：不要只看配置，看上一次执行记錄的時間戳。
- 检查内容發布時間：後台顯示的時間、頁面展示的時間、结构化資料里的時間，三者應一致。
- 核對站点地图里的最後修改時間：如果站点地图輸出的時間明顯晚于或早于實际更新時間，蜘蛛會據此判断内容新舊。
常被忽略的几個细节
- 服務器返回的 HTTP 時間头用的是 GMT，和日誌里的本地時間不是一回事，對比时注意換算。
- 有夏令时的地区，如果系統没装时区資料更新，時間會整体偏一小时。
- 容器和虚拟机可能繼承宿主机时区，也可能不繼承，迁移之後要重新確認。
- 資料库里的時間字段用的是 UTC 還是本地時間，最好在表设計阶段就定下来並寫清楚。
- 同一條日誌被多個系統采集时，采集端如果打了自己的時間戳，两套時間並存，排查时容易混淆。
时区問题不會让網站立刻出错，但會让所有基于時間的判断悄悄偏一点。等积累到需要對照日誌复盘的时候，這点偏差會消耗掉大量時間。
改完之後怎么驗證
調整时区後，挑一條刚产生的日誌，和你在頁面上做的一次訪問對照，看時間是否對得上。再看一次定时任務的执行记錄和缓存過期時間。如果站点有多個节点或者同时用了 CDN，记得逐個確認，因為改了一台不代表全线统一。
把时区和時間基准寫進部署清單，新机器上线时顺手核對一次，比事後追溯省事得多。