这问题我之前帮好几个同事排查过，确实挺让人摸不着头脑的——明明没看到任何编译错误，构建却直接失败，核心原因其实和VS2015的增量构建机制对时间戳的处理bug有关：

• VS2015的增量构建完全依赖文件时间戳来判断哪些文件需要重新编译。当你更改系统时区时，本地时间会发生跳转，但部分文件的时间戳是基于旧时区的UTC时间转换而来的，这就会让VS的构建引擎出现时间逻辑混乱：比如它会误以为某些文件的“修改时间”比当前系统时间还晚，或者依赖项的时间戳校验不通过，但又没法定位到具体的错误点，最终只能默默标记构建失败，连错误日志都不给。
• 更深层的问题是VS2015对系统时间的兼容性缺陷：它没有正确区分本地时间和UTC时间的转换规则，时区变更后，缓存的文件时间信息和系统新时区下的时间完全不匹配，导致增量构建的依赖链直接断裂，但又无法输出明确的错误提示。

你提到的关闭重启VS、重新加载解决方案确实能解决，但这只是临时的——本质是清空了VS缓存的文件时间戳信息，让它重新读取当前时区下的文件时间。可如果需要频繁变更时区，每次重启或重载大型解决方案的耗时简直无法接受。

给你几个更可行的替代方案：

• 禁用增量构建：右键项目→属性→生成，找到“增量构建”选项并取消勾选。这样VS会每次全量编译所有文件，跳过时间戳校验环节，彻底规避时区相关的时间逻辑问题。缺点是编译时间会变长，但对于时区频繁变化的场景来说，稳定性优先。
• 手动清理构建缓存：不用重启VS，直接删除项目根目录下的obj和bin文件夹，然后在VS里执行“清理解决方案”，再重新构建。这会强制VS重新生成所有中间文件，相当于局部重置时间戳缓存，比重启整个VS快很多。
• 强制时间同步：时区变更后，手动触发系统时间同步（比如Windows下可以在日期和时间设置里点击“立即同步”），尽量缩小本地时间和UTC时间的偏差，能降低这个问题出现的概率，但没法完全避免。

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