服务器时间是最不起眼的配置之一，很多人装完系统就没再看过它。但它同时牵着前台显示、后台日志、定时任务，以及蜘蛛读到的 lastmod。时区对不上，问题不会立刻炸出来，而是慢慢变成“发布时间怪怪的”“日志对不上号”这类说不清的小毛病。
时区没统一，先乱的是发布时间
一台服务器上通常有三层时间：操作系统、运行环境（比如 PHP 的 date.timezone）、数据库。三层各写各的时区，前台就会看到奇怪的结果——晚上十一点发的文章显示成第二天早上七点，或者干脆显示一个“未来时间”。读者未必在意，但编辑回看历史内容时会很混乱，排期和更新节奏也跟着错。
比较省事的做法是：存储统一用 UTC，展示时再按站点主要访客所在时区转换。如果嫌麻烦，至少保证系统、应用、数据库三层一致，并把结论写进运维记录，别让下一个人再猜一遍。
时间错乱容易在哪些地方露头
- 文章发布时间、评论时间、用户注册时间
- Sitemap 与 RSS 里的 lastmod、pubDate
- 访问日志的时间戳，直接决定你怎么判断蜘蛛的到访规律
- 备份、清理缓存、生成静态页等定时任务
- 证书到期提醒、缓存过期时间等依赖时间的配置
排查顺序建议：先看系统时间，再看应用时区，然后看数据库，最后看日志输出。一层一层对，比到处乱翻快得多。
和蜘蛛有关的两个细节
lastmod 不要随口写
有些 CMS 会在保存、换模板甚至全站重建时，把所有页面的修改时间刷成当前时间。蜘蛛第一次来可能还会多跑几趟，发现内容根本没变之后，对 lastmod 的信任就会打折。反过来，页面确实改了却一直不更新 lastmod，蜘蛛也没有理由优先重访。老实记录比“看起来很勤快”有用。
日志时间对不上，分析就白做
服务器日志常用 UTC，而你在本地时间下午三点打开看，看到的可能是早上七点的记录。跨天统计抓取量、判断蜘蛛集中到访的时段、对照自己几点发的内容，都会偏一截。没看出问题，往往只是因为偏差刚好是整数小时，不容易察觉。
一次十分钟的自查
- 在服务器上执行 date 和 timedatectl，确认当前时间与时区。
- 检查运行环境和数据库连接使用的时区，是否与系统一致。
- 发一条测试内容，对比后台、前台、数据库里记录的三个时间。
- 取一段访问日志，看时间戳与当前时间的差值是不是整小时。
- 查看定时任务最近几次的实际执行时间是否符合预期。
- 确认证书到期、缓存过期这类提醒没被时区带偏。
- 把结论记下来：统一用哪个时区、在哪里改，避免下次又改回去。
顺手的几个小调整
给编辑看的时间用本地时区，对外输出的时间（RSS、sitemap、HTTP 响应头）尽量用带时区的 ISO 8601 格式，减少解析歧义。开启 NTP 同步，避免服务器长时间运行后慢慢跑偏。改完时区后要专门检查一遍定时任务，有些任务会在改动的那一刻被触发一次，甚至干脆错过。
时间不出问题的时候，没有人会夸它。真出问题时，往往是一串连锁反应：编辑以为内容没发出去，运营以为蜘蛛没来，技术以为程序有 bug。花十分钟核对一次，比事后翻日志找原因划算得多。