是否可全局或针对当前进程设置计算机运行时长模拟系统uptime

你不需要修改Windows全局的系统运行时长配置，有两类完全在当前进程内生效的方案可以满足测试需求，按照推荐优先级排序如下：

如果你可以修改待测代码的源码，这是最稳定、无任何副作用的标准实现方式：

• 抽象出专门的系统运行时间获取接口，比如定义ITickCountProvider，对外暴露GetTickCount()方法
• 生产环境的接口实现直接调用Environment.TickCount返回真实的系统运行毫秒数
• 测试环境的接口实现可自定义返回值：要模拟系统已运行X天，直接返回X * 24 * 3600 * 1000即可，还可以轻松模拟TickCount从Int32.MaxValue溢出跳转到Int32.MinValue的边界场景（这也是49.7天循环周期最容易出代码bug的场景）

该方案不需要任何系统权限，不会对进程外的任何逻辑产生影响，测试灵活度最高，是工程上的首选方案。

如果你无法修改待测程序的源码，可以通过进程内挂钩系统API的方式篡改Environment.TickCount的返回值，同样仅对当前进程生效：

• .NET的Environment.TickCount内部本质是调用kernel32.dll导出的GetTickCount或GetTickCount64系统API获取数值
• 你可以在进程启动后，通过用户态API Hook技术，将上述两个系统API的入口修改为你自定义的函数地址
• 自定义函数内按照你需要模拟的运行时长计算返回值即可，不需要返回真实的系统运行时长
• 该Hook仅在当前进程的地址空间内生效，其他进程调用系统API拿到的仍然是真实的系统运行时长，不会产生全局影响

注意事项：

• 32位和64位程序需要对应匹配的Hook实现
• 极少数不通过系统API直接读取硬件时间戳的代码无法被该方案覆盖，但绝大多数常规.NET程序都可以正常拦截

不建议使用内核级Hook、修改系统时间等全局生效的方案实现测试需求，这类方案需要高权限，会影响系统内所有进程的运行，稳定性差，且完全不符合你要求的进程隔离的安全规则。

注意：测试时不要只模拟常规运行时长，一定要覆盖49.7天溢出的边界场景，绝大多数依赖TickCount做时间差计算的代码bug都出现在溢出跳转的节点。

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