DateTimeOffset 是 C# 时区处理的可靠起点，应优先使用 TimeZoneInfo.ConvertTime 等方法配合带偏移量的时间值进行转换，统一以 UTC 为中转基准，并注意时区 ID 的平台差异与显示名匹配风险。
DateTimeOffset 是 C# 时区转换的可靠起点，DateTime 单独用容易出错——尤其当 Kind 是 Unspecified 时，系统会按本地时区瞎猜，结果不可控。
用 TimeZoneInfo.ConvertTime 做跨时区转换
这是最直接、最可控的方式，适用于已知源时区和目标时区的场景。关键不是传 DateTime，而是传带偏移量的时间值（比如 DateTimeOffset 或明确标记 Kind 的 DateTime）。
- 如果源时间是本地时间，且你确定它属于“中国标准时间”，就别用
DateTime.Now直接传——先用TimeZoneInfo.FindSystemTimeZoneById("China Standard Time")拿到时区对象，再用new DateTimeOffset(dateTime, tz.GetUtcOffset(dateTime))构造带偏移的值 - 目标时区 ID 必须用系统识别的名称，比如
"Eastern Standard Time"（Windows）或"America/New_York"（.NET 6+ 支持 IANA，但需启用AppContext.SetSwitch("System.Globalization.UseNls", false)） - 避免用
TimeZone.CurrentTimeZone：它已被标记为过时，且不支持夏令时自动切换
从 UTC 出发做统一中转
服务端存时间、数据库字段、API 返回，一律用 DateTimeOffset.UtcNow 或 DateTime.UtcNow（后者需确保 Kind == Utc）。所有转换都以 UTC 为枢纽，能彻底规避“本地时间在不同服务器上解析不一致”的坑。
-
DateTimeOffset.UtcNow.ToUnixTimeSeconds()是获取标准 Unix 时间戳的推荐方式，比手算DateTime.UtcNow - new DateTime(1970,1,1,0,0,0, DateTimeKind.Utc)更安全 - 前端传来的带偏移时间字符串（如
"2024-06-01T12:00:00+09:00"），优先用DateTimeOffset.Parse()解析，它能保留原始偏移；别用DateTime.Parse()，它可能丢掉偏移或错误归类为Local - 用
TimeZoneInfo.ConvertTimeFromUtc()把 UTC 转成某地本地时间，比反向调用更稳定——因为 UTC 到任意时区的映射是单向确定的
处理用户输入的时区 ID 或显示名
用户下拉菜单选的是 “北京时间”、“东京时间” 这类显示名？别直接喂给 FindSystemTimeZoneById ——它只认 ID，不认中文名或模糊别名。
- Windows 系统时区 ID 示例：
"China Standard Time"、"Tokyo Standard Time"、"GMT Standard Time"；Linux/macOS（.NET 6+）倾向用 IANA 名："Asia/Shanghai"、"Asia/Tokyo"、"Europe/London" - 若必须支持显示名搜索，可用
TimeZoneInfo.GetSystemTimeZones()遍历，检查.DisplayName或.StandardName是否匹配，但注意这些字段语言依赖当前线程CultureInfo - 显示名不稳定：同一时区在不同 Windows 版本中
DisplayName可能含年份（如 “(UTC+08:00) 北京，重庆，香港特别行政区，乌鲁木齐 (2025)”），硬匹配会失败
真正麻烦的不是写对一行转换代码，而是确保整个链路里每个时间值都有明确的时区上下文——从 HTTP 请求头里的 User-Timezone，到数据库字段类型是否存 datetimeoffset，再到日志里打印的是 ToString("o") 还是 ToString()。漏掉一环，问题就会在某个夏令时切换日突然爆发。
