datetime序列化为utc是因序列化器按kind处理：unspecified默认转utc，local先转utc再加z，仅utc才原样保留；正确做法是存储用utc，返回前转目标时区并设kind=unspecified，或改用datetimeoffset。
为什么 DateTime 序列化到 JSON 总是变成 UTC 时间？
因为 .NET 默认用 System.Text.Json（.NET Core 3.0+）或 Newtonsoft.Json（旧项目）序列化 DateTime 时，会按 DateTimeKind 做处理：如果值是 DateTimeKind.Unspecified，多数序列化器会**默认当作本地时间转成 UTC 输出**；如果是 DateTimeKind.Local，则先转为 UTC 再加 Z 后缀；只有明确标记为 DateTimeKind.Utc 的才原样保留。前端收到带 Z 的字符串（如 "2024-05-20T08:30:00Z"），new Date() 就会按 UTC 解析——结果在东八区显示成下午 4:30，明显错位。
如何让 API 返回的 JSON 时间字段保持原始时区（比如北京时间）？
关键不是“去掉 UTC”，而是**显式控制时区语义和序列化行为**。不能依赖 ToString("yyyy-MM-dd HH:mm:ss") 拼字符串（破坏类型安全、无法反序列化），也不该全局禁用时区转换（影响其他逻辑）。推荐做法：
- 后端存储统一用
DateTimeKind.Utc（最佳实践），但对外返回前，用TimeZoneInfo.ConvertTimeFromUtc()转成目标时区的DateTime，并设Kind = DateTimeKind.Unspecified—— 这样序列化器不会自动转 UTC，只输出“裸时间”字符串（如"2024-05-20T16:30:00"） - 或者更稳妥：改用
DateTimeOffset类型，它自带偏移量（如new DateTimeOffset(DateTime.Now, TimeSpan.FromHours(8))），序列化后是"2024-05-20T16:30:00+08:00"，前端可直接解析为本地时间 - 若必须用
DateTime且需保留时区信息，可在 JSON 中额外加一个字段，如"time": "2024-05-20T08:30:00", "timezone": "Asia/Shanghai"，由前端自行处理
System.Text.Json 全局配置时区行为的坑
很多人想通过 JsonSerializerOptions 的 DefaultIgnoreCondition 或自定义 JsonConverter<datetime></datetime> 来统一处理，但要注意：
-
JsonSerializerOptions.Converters.Add(new JsonConverter<datetime>())</datetime>必须覆盖全部逻辑，包括Read()和Write()，漏掉一个就会反序列化失败 - 不要在 converter 里调用
DateTime.ToLocalTime()—— 它依赖服务器所在机器的时区，而服务器很可能在 UTC 时区，结果把本应是北京时间的值又转错一次 - 全局 converter 会影响所有
DateTime字段（包括数据库创建时间、日志时间等），容易误伤。建议只对特定 DTO 属性用[JsonConverter(typeof(CnTimeConverter))]特殊处理
前端拿到时间字符串后怎么正确显示为用户本地时间？
如果后端返回的是无时区标记的时间（如 "2024-05-20T16:30:00"），new Date(str) 会按**浏览器本地时区**解释这个字符串 —— 这其实是你想要的（比如用户在北京，就显示 16:30；在纽约，就显示 04:30）。但前提是后端返回的确实是“该时区下的本地时间字符串”，而不是错误地把 UTC 时间当成本地时间输出（例如把 2024-05-20T08:30:00Z 错写成 "2024-05-20T08:30:00"）。
真正要警惕的是：后端用 DateTime.Now.ToString("o") 直接输出，而服务器时区是 UTC，结果返回了 "2024-05-20T08:30:00.0000000Z"，前端却当成北京时间解析——这种隐式依赖服务器配置的问题，上线后很难排查。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
