绝大多数场景下应优先使用 DateTime.UtcNow，因其提供统一、稳定、不受时区和夏令时影响的 UTC 时间基线，适用于日志、缓存、JWT、分布式调度等；DateTime.Now 仅适合本地界面展示。
DateTime.Now 和 DateTime.UtcNow 到底该用哪个
绝大多数场景下，你应该优先用 DateTime.UtcNow，而不是 DateTime.Now。因为 DateTime.Now 返回本地时区时间，受系统时区、夏令时、甚至用户手动改时间影响，一旦部署到多时区服务器或做时间比较/存储，很容易出错。
比如 Web API 返回时间戳、数据库写入创建时间、计算任务超时——这些都该基于统一时间基线，DateTime.UtcNow 就是那个基线。
-
DateTime.Now适合仅面向当前用户界面展示（如 WinForms 本地日历控件） -
DateTime.UtcNow适合日志记录、缓存过期、JWTexp字段、分布式任务调度 - 两者返回的
Kind属性不同：DateTime.Now.Kind == DateTimeKind.Local，DateTime.UtcNow.Kind == DateTimeKind.Utc，后续序列化或转换时行为会不同
DateTime.Now.ToString() 为什么有时格式不对
直接调用 ToString() 依赖当前线程的 CultureInfo，在服务器上可能不是你开发机的区域设置，导致 "MM/dd/yyyy" 变成 "dd/MM/yyyy" 或时间分隔符异常。
更糟的是，如果没指定格式，.NET 默认用短日期模式，不同系统输出长度和顺序可能不一致，前端解析容易失败。
- 固定格式输出请用明确字符串模板：
DateTime.UtcNow.ToString("yyyy-MM-dd HH:mm:ss") - 需要 ISO 8601 标准格式（推荐 API 交互）：用
DateTime.UtcNow.ToString("o")，输出类似"2024-05-22T14:35:02.1234567Z" - 避免用
ToString()无参重载，尤其在跨环境部署时
DateTime 转换时区容易踩的坑
别用 DateTime.ToLocalTime() 或 ToUniversalTime() 处理非本机时区的时间——它们只认 Kind 属性，不认实际时区含义。比如一个从数据库读出的 DateTime 值，若 Kind == DateTimeKind.Unspecified，调用 ToUniversalTime() 会按本地时区解释再转 UTC，结果错得离谱。
- 读取外部时间（如 JSON、数据库字段）时，务必确认它的原始时区含义，并用
DateTime.SpecifyKind()显式标注 - 跨时区转换请用
TimeZoneInfo：比如把北京时间转纽约时间，用TimeZoneInfo.ConvertTimeBySystemTimeZoneId(dt, "China Standard Time", "Eastern Standard Time") - SQL Server 的
datetimeoffset类型能保留时区偏移，C# 对应DateTimeOffset，比DateTime更安全
性能敏感场景下 DateTime.Now 的替代方案
高频调用 DateTime.Now（比如每毫秒打点、游戏帧时间）会有明显开销，因为它每次都要查系统时钟并做时区换算。
.NET 6+ 提供了轻量级替代：DateTime.UtcNow 本身比 DateTime.Now 快约 30%，但更进一步可考虑 Stopwatch.GetTimestamp() 配合 Stopwatch.Frequency 做相对时间测量；若必须绝对时间，DateTimeOffset.UtcNow 在某些 JIT 场景下也略优。
- 不要在 tight loop 里反复调用
DateTime.Now，提取一次复用 - 日志打点等场景，优先用
DateTimeOffset.UtcNow，它自带时区信息且构造开销略低 - 注意
DateTime.Now在 Windows 上底层调用GetLocalTime()，而DateTime.UtcNow调用GetSystemTimeAsFileTime()，后者更底层、更稳定
时区、Kind、序列化格式、性能——这四个点串起来，才是 C# 时间处理真正容易翻车的地方。很多人只记得“用 Now”，却忘了它背后绑定的是系统时钟状态和文化设置，一换环境就露馅。
