Stopwatch与TimeProvider的GetTimestamp、GetElapsedTime方法差异及选型建议

.NET 7 为System.Diagnostics.Stopwatch新增了GetElapsedTime方法，搭配GetTimestamp使用的示例代码如下：

long start = Stopwatch.GetTimestamp();

await LongRunningTaskAsync();

TimeSpan elapsed = Stopwatch.GetElapsedTime(start);

Console.WriteLine($"Duration: {elapsed}");

而在.NET Framework中，System.TimeProvider.System提供了几乎完全一致的API：

long start = TimeProvider.System.GetTimestamp();

await LongRunningTaskAsync();

TimeSpan elapsed = TimeProvider.System.GetElapsedTime(start);

Console.WriteLine($"Duration: {elapsed}");

从代码外观和功能上看，Stopwatch可以直接被TimeProvider.System替代，以下针对核心问题逐一解答：

一、二者是否存在实际差异？ #

功能和性能上没有本质差异——TimeProvider.System.GetTimestamp()和Stopwatch.GetTimestamp()底层调用的是同一个高精度计时器源，对应的GetElapsedTime方法也基于相同的计时器频率计算时间差。

唯一的细微区别在于语义：Stopwatch是专门用于计时的工具类，语义更聚焦；而TimeProvider是抽象类，TimeProvider.System只是它的默认系统时间实现。

二、为什么.NET 7要给Stopwatch添加同名方法？ #

1. API完整性：此前Stopwatch只有GetTimestamp方法，开发者需要自行通过(end - start) / Stopwatch.Frequency计算时间差，新增GetElapsedTime让API更完整，无需额外手动计算。
2. 使用习惯与迁移友好：对于习惯使用Stopwatch的开发者，无需切换到TimeProvider就能使用简洁的计时API；从.NET Framework迁移到.NET 7+的项目，也可根据需求选择保留或替换原有调用。

三、有选择空间时应该使用哪一个？ #

• 纯计时场景：优先用Stopwatch.GetElapsedTime()，语义更明确，符合“专门工具做专门事”的原则。
• 需要抽象或测试场景：如果代码需要依赖时间源（比如单元测试中要模拟时间流逝），则选择TimeProvider抽象类，通过注入不同的TimeProvider实现（如模拟时间的测试类）解耦代码，提升可测试性。

内容的提问来源于stack exchange，提问作者baltermia