DateTime.Now 和 DateTime.UtcNow 不能直接用于跨时区比对，因它们无时区偏移信息且 Kind 标记易导致错误转换；应优先使用 DateTimeOffset 和 TimeZoneInfo.ConvertTime 安全转换。
为什么 DateTime.Now 和 DateTime.UtcNow 不能直接用于跨时区时间比对
因为 DateTime 类型本身不带时区上下文，它的 Kind 属性只有 Unspecified、Local、Utc 三种标记，但不会自动携带偏移量或时区 ID。一旦你用 DateTime.Parse("2024-06-01 14:00") 解析字符串，它默认是 Unspecified，后续调用 .ToLocalTime() 或 .ToUniversalTime() 就可能按错规则转换——比如在夏令时切换日附近出错。
- 永远优先用
DateTimeOffset表示带偏移的时间，它自带Offset属性，能明确表达“北京时间 +08:00”这类语义 - 读取系统本地时间请用
DateTimeOffset.Now，不是DateTime.Now；它返回的是带当前系统时区偏移的完整值 - 跨时区转换必须通过
TimeZoneInfo，不能靠手动加减小时数（夏令时、历史时区变更会让这种做法崩掉）
TimeZoneInfo.ConvertTime 怎么安全做时区转换
这个函数是 .NET 唯一推荐的、能处理历史时区规则（比如中国 1992 年取消夏令时）的转换方式。它依赖 Windows 注册表或 ICU（.NET 6+ Linux/macOS），所以行为跨平台一致，但要注意参数顺序和目标时区有效性。
- 源时间必须是
DateTimeOffset或DateTime且Kind != Unspecified；否则抛ArgumentException - 目标时区 ID 要用标准名称，比如
"China Standard Time"（Windows）或"Asia/Shanghai"（IANA，.NET 6+ 支持映射） - 别用
TimeZoneInfo.Local当目标时区去转“其他时区 → 本地”，因为用户可能改过系统时区设置，导致逻辑错乱；显式指定目标时区更可靠 - 示例：
TimeZoneInfo.ConvertTime(DateTimeOffset.Now, TimeZoneInfo.FindSystemTimeZoneById("UTC"), TimeZoneInfo.FindSystemTimeZoneById("China Standard Time"))
同步 NTP 时间时，为什么不能只调用一次 NtpClient 就更新系统时钟
操作系统内核管理硬件时钟（RTC）和系统时间（system clock）是两套机制。普通用户代码没有权限直接写 RTC，而调用 SetSystemTime 这类 Win32 API 需要 SE_SYSTEMTIME_NAME 特权，且 Windows 默认禁止非 SYSTEM 进程修改系统时间——哪怕你用了管理员权限启动程序，也会被策略拦截。
- 应用层能做的，只是计算本地时钟与 NTP 服务器的偏差（offset）、漂移（drift），然后建议用户手动校准，或调用
W32Time服务（需配置组策略） - 真要自动同步，请走系统级方案：启用 Windows 内置的
w32time服务，或用 PowerShell 命令w32tm /resync触发（需要管理员权限） - 自己实现 NTP 客户端时，注意 UDP 包超时设为 3–5 秒，至少发 3 次请求取中位数 offset，避免单次网络抖动影响结果
DateTimeOffset.Now 返回的时间为什么在 Docker 容器里总是 UTC
Docker 容器默认不挂载宿主机的时区文件（/etc/localtime、/usr/share/zoneinfo），.NET 运行时检测不到有效时区配置，就退回到 UTC。这不是 bug，是容器隔离的正常表现。
- 修复方法：运行容器时加
-v /etc/localtime:/etc/localtime:ro，或构建镜像时 COPY 宿主机的/usr/share/zoneinfo/Asia/Shanghai并设环境变量TZ=Asia/Shanghai - 验证是否生效：在容器内执行
date命令，输出应含正确时区缩写（如 CST），而非 UTC - 代码里别依赖
TimeZoneInfo.Local的 ID 名称，它在容器里可能是"UTC"；统一用TimeZoneInfo.FindSystemTimeZoneById("Asia/Shanghai")显式指定
