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 或查表。
