Environment.TickCount 返回负数是设计行为而非 bug：其为32位有符号整数，约24.9天后溢出回绕；应使用TickCount64、差值计算或DateTime.UtcNow替代，注意休眠暂停、分辨率低及容器中无效等问题。

为什么 Environment.TickCount 返回负数？

它不是 bug，是设计如此：Environment.TickCount 返回的是 int 类型，单位毫秒，从系统启动开始累加；32 位有符号整数最大值约 2,147,483,647 毫秒（≈24.9 天），超限后会回绕成负数。

• 别用 == 判断是否“刚启动”，负值可能只是系统已运行 25+ 天
• 比较两个 TickCount 值时，用差值计算（(b - a) & 0x7FFFFFFF 不可靠，应改用无符号差值逻辑）
• 若需长期稳定计时，改用 Stopwatch.ElapsedMilliseconds 或 DateTime.UtcNow

获取开机至今毫秒数的稳妥写法

直接读 Environment.TickCount 简单，但要注意类型和溢出语义。C# 6+ 推荐用以下方式规避负值误判：

long uptimeMs = Environment.TickCount64; // ✅ .NET Core 2.0+ / .NET 5+ 默认可用
// 或兼容旧框架：
long tick = Environment.TickCount & 0xFFFFFFFFL;
if (Environment.TickCount < 0) tick += 0x100000000L;

• Environment.TickCount64 是 long，彻底解决溢出问题，但仅在较新运行时可用
• 老版本（如 .NET Framework 4.7.2）必须手动处理符号回绕，不能直接转 long
• 该值反映的是内核启动时间，不等于用户登录时长，也不含休眠时间（Windows 休眠后 TickCount 会暂停）

和 GetTickCount64() Win32 API 的区别在哪？

Environment.TickCount64 底层就调用了 GetTickCount64()，但封装更安全；而手动 P/Invoke 调用需自己处理平台兼容性：

C#

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

[DllImport("kernel32.dll")]
private static extern ulong GetTickCount64();

• WinXP 不支持 GetTickCount64，但 Environment.TickCount64 在不支持时会降级为模拟逻辑（仍可能溢出）
• 手动调用返回 ulong，无需位运算，但多一层互操作开销，且要处理 MissingMethodException
• 两者都受系统休眠影响：睡眠期间计数停止，唤醒后继续——这不是误差，是 Windows 设计行为

别拿它做精确时间差或调度依据

TickCount 分辨率通常为 10–16ms（取决于硬件和系统设置），不适合高精度场景：

• 定时器抖动、线程调度延迟会让相邻两次读值差出 15ms 甚至 30ms
• 不要用它实现 Thread.Sleep(1) 级别的轮询等待，改用 Stopwatch + SpinWait 或异步等待
• 服务监控中记录“已运行 X 小时”可以，但告警阈值设成“> 86400000ms”不如用 DateTime.UtcNow - bootTime 更直观

真正容易被忽略的是：这个值在容器环境（如 Linux 上的 .NET 容器）里毫无意义——它读的是宿主机内核启动时间，不是容器启动时间。