DateTime.UtcNow 在高并发下通常比 DateTime.Now 快 2–5 倍，因其直接读取硬件计时器与系统 tick 偏移，而 DateTime.Now 需查时区缓存、做本地化转换（含夏令时计算），引发锁竞争与缓存行争用。
DateTime.UtcNow 在高并发下比 DateTime.Now 快多少？
在高并发场景（比如每秒数万次时间戳生成）中，DateTime.UtcNow 通常比 DateTime.Now 快 2–5 倍，具体取决于操作系统和 .NET 版本。根本原因不是“UTC 更简单”，而是 DateTime.Now 每次调用都需查系统时区缓存、做本地化转换（含夏令时规则计算），而 DateTime.UtcNow 直接读取硬件计时器 + 系统 tick 偏移，路径更短、无锁竞争更少。
为什么 DateTime.Now 在多线程下容易成为瓶颈？
DateTime.Now 内部会调用 TimeZoneInfo.Local.GetUtcOffset()，该方法在首次访问时初始化全局时区数据，后续调用仍需读取线程安全的缓存结构；在 .NET 6+ 中虽已优化为无锁读，但仍有额外分支判断和内存访问层级。高并发下多个线程频繁争抢同一缓存行（cache line），可能引发 false sharing 或增加 L3 缓存压力。
- Windows 上
DateTime.Now底层依赖GetLocalTime+ 时区数据库查询 - Linux/macOS 上通过
localtime_r+ TZ 数据解析，开销更大 - 每次调用都触发
TimeZoneInfo._cachedData的 volatile 读取（.NET 5+）
实际压测中要注意哪些干扰因素？
直接用 Stopwatch 测单次调用没意义——JIT 预热、GC 干扰、CPU 频率波动都会掩盖真实差异。必须用 BenchmarkDotNet 做受控测试，并注意：
- 禁用
DateTime.Now的首次初始化开销：在 Benchmark 方法外先调用一次DateTime.Now - 避免在循环内混用两种调用，防止 CPU 分支预测失效
- 确认运行时是
Server GC模式（DOTNET_gcServer=1），否则 GC 暂停会污染结果 - .NET 6+ 中
DateTime.UtcNow已被内联且部分路径走rdtsc（若支持），而DateTime.Now仍未内联
[MemoryDiagnoser]
public class DateTimeBench
{
[Benchmark] public DateTime UtcNow() => DateTime.UtcNow;
[Benchmark] public DateTime Now() => DateTime.Now;
}
什么情况下还必须用 DateTime.Now？
仅当业务逻辑明确依赖本地时区语义时才用 DateTime.Now，例如：
- 日志中需按用户所在地显示“今天下午 3 点”（而非 UTC 时间）
- 定时任务调度器要按本地日历解释“每天凌晨 2 点”（涉及夏令时跳变）
- 与遗留系统交互，对方只认本地时间字符串（且未带时区标识）
但即便如此，也建议改为先用 DateTime.UtcNow 获取时间点，再用 TimeZoneInfo.ConvertTimeFromUtc() 显式转换——这样既可控、又可缓存 TimeZoneInfo.Local 实例，避免重复查表。
真正影响性能的从来不是“UTC 还是本地”，而是“是否在 hot path 上做了隐式、不可控的时区计算”。高频时间戳场景，默认选 DateTime.UtcNow；需要本地语义时，把转换逻辑提到外围、缓存好时区对象、避免在循环里反复 new 或查表。