Linux时间管理由RTC、系统时钟、时区层和NTP服务四层协同；改date仅调系统时钟，关机后错乱多因RTC与系统时钟未对齐或RTC模式（UTC/本地）不一致。
Linux 中时间管理不是单一“一个时钟”，而是由硬件时钟（RTC）、系统时钟（内核维护的 UTC 时间）、时区解释层和同步服务四层协同工作的结果。直接改 date 只动系统时钟，不碰硬件；关机后时间错乱，大概率是 RTC 与系统时钟没对齐或 RTC 被误设为本地时间。
硬件时钟 vs 系统时钟：两个独立但需协同的源
主板上的硬件时钟（RTC）靠电池供电，关机也走时；系统时钟是内核运行时用的软件时钟，基于 UTC，启动时从 RTC 加载一次，之后完全独立运行。二者不同步会导致重启后时间跳变。
-
hwclock --show查看 RTC 当前值（注意它默认按本地时间显示，除非加--utc） -
date显示的是系统时钟（已应用时区转换），date -u才是纯 UTC - 常见错误：在双系统（如 Win + Linux）中，Windows 默认把 RTC 当作本地时间，而 Linux 默认当 UTC —— 这会导致一方时间总快/慢 8 小时
- 解决办法：统一 RTC 为 UTC（推荐），执行
sudo hwclock --set --utc --date="2026-01-23 17:35:00"后再sudo hwclock --systohc
时区不是“改时间”，而是“改解释规则”
Linux 系统时钟永远是 UTC，/etc/localtime 只是一个指向 /usr/share/zoneinfo/Asia/Shanghai 的软链接，它不存储时间，只告诉 libc 如何把 UTC 转成你看到的“北京时间”。
- 用
timedatectl set-timezone Asia/Shanghai安全可靠；手动 ln -sf 改链接容易出权限或路径错误 -
TZ=Asia/Shanghai date可临时切换时区输出，不影响系统全局 - 错误现象：“
date显示正确，但 cron 任务早 8 小时执行”——多半是 crond 服务未重载时区，或容器里没挂载 /etc/localtime
NTP 同步不是“开个服务就行”，得看用 chronyd 还是 systemd-timesyncd
ntpd 已基本被弃用；chronyd 是当前主流，适合虚拟机、移动设备等网络不稳场景；systemd-timesyncd 更轻量，但只支持简单 NTP（不支持 ntpdate 那种单次校准）。
- 检查是否生效：
timedatectl status看 “System clock synchronized: yes” 和 “NTP service: active” - chronyd 配置文件是
/etc/chrony/chrony.conf，国内推荐加server ntp.aliyun.com iburst - 禁止手动
date -s后不运行sudo chronyc makestep：chronyd 默认拒绝大跨度时间调整，会卡在“unsynchronized”状态 - 容器环境常禁用 NTP，得靠宿主机同步后挂载 /etc/localtime + 使用
--cap-add=SYS_TIME才能调系统时钟
最易被忽略的一点：硬件时钟的 UTC/本地时间模式必须和系统配置一致，且这个设置在 BIOS/UEFI 层面也可能被覆盖 —— 某些品牌主板（如部分 Dell、Lenovo）的 BIOS 会强制把 RTC 当作本地时间写入，此时仅靠 Linux 侧配置无法根治，得进 BIOS 关闭 “RTC Local Time” 类似选项。
