C#中测量程序启动后已运行时长的最高效方法（时长可达小时级）

首选方案：使用Stopwatch类做计时基准 #

这是.NET框架原生提供的、专为高精度耗时测量设计的工具，完全适配你对低开销、高可靠的长时计时需求：

• 可靠性拉满：底层直接对接操作系统提供的单调高性能计时器，完全不受系统手动改时间、NTP时钟同步校准、夏令时/时区切换的影响，连续运行数小时也不会出现时长跳变、计算偏差的问题。
• 资源开销极低：单实例Stopwatch仅占几十字节的托管内存，每次读取运行时长的操作是直接读内核计数器值，全程没有额外的托管对象分配，连续运行几小时也不会产生GC压力，完全满足你对运行效率和内存占用的要求。
• 支持超长时间测量：底层计数器是单调递增的无溢出设计，连续运行数天、数周的计时精度都有保障，完全覆盖小时级的测量需求，不会因为计时时间长出现精度丢失。

具体实现非常简单：

1. 在程序入口的最开头初始化并启动计时器：
   var runningTimer = Stopwatch.StartNew();
2. 任意位置需要读取运行时长时，直接访问实例属性即可：
   • 读取以小时为单位的总时长：runningTimer.Elapsed.TotalHours
   • 格式化为易读的时分秒格式：runningTimer.Elapsed.ToString(@"hh\:mm\:ss")
   • 读取毫秒级统计值：runningTimer.ElapsedMilliseconds

对你现有方案的优化提示 #

你现在用DateTime now = DateTime.Now;存启动时间的实现存在两个明显短板：

• 可靠性不足：DateTime.Now读取的是系统挂钟时间，如果程序运行过程中系统时间被校准、手动修改、或者跨时区/夏令时切换，计算出来的运行时长会直接出现跳变，甚至算出负数，对于数小时级的长时运行场景来说风险很高。就算换成不受时区影响的DateTime.UtcNow，也依然解决不了系统时间被主动修改带来的偏差问题。
• 额外开销偏高：每次调用DateTime.Now都会触发一次系统内核调用，相比直接读Stopwatch计数器的操作，单次调用开销高一个数量级，从最高效的实现要求来说完全没有必要。

补充说明：如果你的程序运行在Windows 7及以上、所有现代Linux/macOS系统上，Stopwatch会直接调用硬件级的高性能计时器，不存在回退到挂钟计时的情况；就算是非常老旧的不支持高性能计时器的系统，Stopwatch也会自动回退到和DateTime.UtcNow一致的计时逻辑，不会出现兼容性问题。

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