日期和时间相关的 bug，永远是写业务代码时容易忽视的大坑。我刚入行时，几乎每个时间戳都直接DateTime.Now，直到有一天，线上报了个“订单时间提前了6小时”的严重 bug。今天聊聊.NET中DateTime.Now的那些坑，以及如何优雅地处理时间。

DateTime.Now 与 DateTime.UtcNow 究竟差了什么？

真实场景

想象下，你在中国服务器上用DateTime.Now记录订单创建时间，把这个时间存数据库，日后用于各种报表、通知，甚至对接海外系统。突然，某天服务器被迁移到伦敦，或者有微服务在其它时区，瞬间表里的时间全错——不是提前就是延后。

两者差别

• • DateTime.Now：返回本地时区时间，受服务器当前所在时区影响。当服务器时区有变动，历史数据就可能混乱。
• • DateTime.UtcNow：UTC 时间，全世界统一，对分布式系统、微服务极其友好。

推荐实践：优先使用 UTC 时间

我现在除了做业务逻辑直接跟 UI 展示相关的，都用DateTime.UtcNow存储，只有UI展示时再做时区转换。这极大减少了跨时区的 bug，也让系统变得健壮。

代码示例

// 写入数据库前
var createdUtc = DateTime.UtcNow;
SaveToDb(orderId, createdUtc); // 存储统一 UTC 时间

// 展示时转换为用户时区
var userTimeZone = TimeZoneInfo.FindSystemTimeZoneById("China Standard Time");
var displayTime = TimeZoneInfo.ConvertTimeFromUtc(createdUtc, userTimeZone);
Console.WriteLine($"订单创建时间: {displayTime}");

开发常见误区

• • **误区一：只有海外业务才用 UTC。**其实只要有多台服务器、云部署，这事就得注意。
• • **误区二：DateTime.Now能自动感知时区变化。**其实它只是当前操作系统时区，不是用户真实时区。

最佳实践清单

• • 数据库存储一律用DateTime.UtcNow。
• • 展示时明确用户时区，做转换。
• • 日志、审计、接口调用时间，也建议用 UTC。

踩坑总结

早期公司时区变更，把表里本地时间误认成 UTC，导致历史订单全乱，临时写了几十行脚本才勉强修正。建议大家把这事早早规范，特别是涉及分布式、微服务、海外业务的项目。

结论：
以后动手写DateTime.Now前，先问自己——这玩意存下来后，时区变了会不会挂？只要有疑虑，直接上DateTime.UtcNow，展示时再转换。本地时间只做瞬时展示，存储永远 UTC，后患无穷全赶走！