这是一个有点学术问题，因为我正在努力思考微软背后使用 double 作为 Interval 属性的数据类型的想法！
首先来自 MDSN Interval 是 Elapsed 事件之间的时间，以毫秒为单位；我会将其解释为离散数字，那么为什么要使用双精度数呢？肯定 int 或 long 更有意义！？
Interval 可以支持 5.768585 (5.768585 ms) 之类的值吗？尤其是当人们认为 System.Timers.Timer 的精度远不及亚毫秒时...... .NET 中最准确的计时器？
对我来说似乎有点愚蠢......也许我错过了一些东西！
反汇编显示间隔是通过调用消耗的，(int)Math.Ceiling(this.interval)因此即使您要指定一个实数，它也会变成一个int使用前。这发生在一个名为UpdateTimer.
为什么？不知道，也许规范说这double在某一时刻是必需的并且改变了？最终结果是double不是严格要求的，因为它最终被转换为 anint并且不能大于Int32.MaxValue根据文档无论如何。
是的，计时器可以“支持”实数，它只是不会告诉你它默默地改变了它们。您可以使用 初始化并运行计时器100.5d，它会将其变为101.
是的，这有点愚蠢：浪费了 4 个字节，潜在的隐式转换，转换调用，显式转换，如果他们只是使用int.
在这里使用双精度的原因是试图提供足够的准确性。
详细说明：系统中断时间片由返回的ActualResolutionNtQueryTimerResolution()给出。NtQueryTimerResolution 由本机 Windows NT 库 NTDLL.DLL 导出。系统时间增量由返回的TimeIncrementGetSystemTimeAdjustment()给出。
这两个值决定了系统计时器的行为。它们是整数值，表示 100 ns 单位。然而，这对于今天的某些硬件来说已经不够了。在某些系统上， ActualResolution返回 9766，相当于 0.9766 毫秒。但事实上，这些系统每秒运行 1024 次中断（通过适当设置多媒体接口进行调整）。1024 次中断一秒将导致中断周期为 0.9765625 ms。这太详细了，它达到了 100 ps 的状态，因此不能以标准的ActualResolution格式保存。
因此，已决定将此类时间参数设置为 double。但是：这并不意味着支持/使用所有可能的值。无论如何， TimeIncrement给出的粒度将保持不变。
在处理计时器时，始终建议查看所涉及参数的粒度。
所以回到你的问题：Can Interval support values like 5.768585 (ms) ?
不，我上面举的系统不能。
但它可以支持5.859375（ms）！
具有不同硬件的其他系统可能支持其他数字。
所以在这里引入双重的想法并不是一个愚蠢的想法，实际上是有道理的。再花 4 个字节来让事情最终正确是一项不错的投资。
我在此处总结了有关 Windows 时间问题的更多详细信息。