DateTime.ParseExact 报错主因是格式字符串与输入未逐字符严格匹配；应优先用 TryParseExact，输入含时区时改用 DateTimeOffset.TryParseExact，并注意跨平台时区 ID 差异及数据库字段类型选择。
DateTime.ParseExact 报“字符串未被识别为有效的 DateTime”
这个错误几乎都因为格式字符串和实际输入不严格匹配。比如输入是 "2024-03-15 14:22:03"，却用了 "yyyy-MM-dd HH:mm:ss.fff"（多写了毫秒位），或输入含空格/不可见字符但没在格式串中预留位置。
实操建议：
- 用
DateTime.TryParseExact替代ParseExact，避免异常中断流程；返回bool更可控 - 格式字符串必须与输入**逐字符对齐**：年份用
yyyy就不能接受yy；HH（24小时制）不能匹配hh（12小时制）输入 - 若输入可能含时区信息（如
"2024-03-15T14:22:03+08:00"），改用DateTimeOffset.TryParseExact，否则必然失败 - 调试时先用
Console.WriteLine(inputString.Aggregate("", (a, c) => a + $"[{(int)c}]"))检查隐藏字符（比如 BOM、全角空格）
ToString("yyyy-MM-dd HH:mm:ss") 输出结果不是预期时区时间
DateTime.ToString 只格式化，不转换时区。如果变量是 DateTimeKind.Unspecified 或 DateTimeKind.Local，直接 ToString 会按当前系统时区解释——但你可能以为它在展示 UTC 时间。
实操建议：
- 明确区分
DateTimeKind.Utc、Local、Unspecified：用DateTime.SpecifyKind(dt, DateTimeKind.Utc)显式标注，别依赖构造函数默认行为 - 跨时区转换必须用
TimeZoneInfo：比如从东八区转东二区，不能靠加减小时数，得用TimeZoneInfo.ConvertTimeBySystemTimeZoneId(dt, "China Standard Time", "Romance Standard Time") - 避免用
ToLocalTime()或ToUniversalTime()处理Unspecified时间——它们会按系统本地规则瞎猜，结果不可靠
使用 DateTime.Now 存数据库后查出来时间错 8 小时
典型场景：服务器在 UTC 时区（如 Linux Docker 容器），而代码用 DateTime.Now 获取本地时间（其实是容器的“本地”，即 UTC），再存进数据库字段类型为 datetime（无时区含义）。前端按浏览器时区渲染时，就自动加了 8 小时偏移。
实操建议：
- 统一用
DateTime.UtcNow存储时间戳，读取后按需转换显示——这是最稳妥的基线做法 - 数据库字段优先选带时区类型：SQL Server 用
datetimeoffset，PostgreSQL 用timestamptz，配合DateTimeOffset类型操作 - EF Core 中映射
DateTimeOffset到datetimeoffset时，确保配置里没意外调用.HasConversion强行转成DateTime - Web API 返回 JSON 时，用
System.Text.Json默认序列化DateTimeOffset为 ISO 8601 带偏移格式（如"2024-03-15T14:22:03+08:00"），前端 new Date() 才能正确解析
DateTimeOffset 与 TimeZoneInfo.GetSystemTimeZones() 不兼容 Windows 和 Linux
TimeZoneInfo.GetSystemTimeZones() 在 .NET 6+ 跨平台支持已改善，但 ID 名称仍不一致：Windows 用 "China Standard Time"，Linux/macOS 用 "Asia/Shanghai"。硬编码 ID 会导致部署到 Docker 容器时报 TimeZoneNotFoundException。
实操建议：
- 用
TimeZoneInfo.FindSystemTimeZoneById()前，先检查运行环境：RuntimeInformation.IsOSPlatform(OSPlatform.Linux)，再动态选 ID - 更可靠的做法是用 IANA 时区 ID（如
"Asia/Shanghai"），并引用Microsoft.Extensions.TimeZoneHandling包（.NET 6+ 内置支持 IANA） - 不要依赖
TimeZoneInfo.Local的 ID 做逻辑判断——它在容器里可能是"UTC"，不代表用户真实所在地 - 测试时务必在目标环境（如 Alpine Linux 容器）里跑单元测试，Windows 开发机上测不出时区 ID 缺失问题
时区不是“换个字符串”就能搞定的事。最常被忽略的是：DateTime.Kind 的隐式状态、数据库字段类型与时区语义的错配、以及跨平台部署时系统时区数据库的差异。这些点一旦出错，表现往往是时间差几小时且难以复现。
