应使用datetimeoffset.utcnow.tounixtimeseconds()获取秒级时间戳，避免手算导致时区偏移和double截断；毫秒级用new datetimeoffset(dt).tounixtimemilliseconds()确保整数运算精度；反解时优先用datetimeoffset而非datetime以保留时区信息。
DateTime转Unix时间戳（秒级）怎么写才不出错
直接用 DateTimeOffset.UtcNow.ToUnixTimeSeconds()，别自己算。C# 6+ 内置支持，精度准、时区稳、无溢出风险。
常见错误是手写 (dt - new DateTime(1970, 1, 1, 0, 0, 0, DateTimeKind.Utc)).TotalSeconds —— 这里如果 dt 是 Local 或 Unspecified，结果会偏移几小时；而且 TotalSeconds 返回 double，强转 long 可能截断小数秒。
- 必须确保输入时间是 UTC：用
dt.ToUniversalTime()或直接从DateTimeOffset构造 - 如果原始
DateTime是本地时间，先调用.ToUniversalTime()再转，不要依赖Kind字段自动推断 - 秒级时间戳够用就别用毫秒级，避免后续 JS 端
Date()解析错位（JS 时间戳是毫秒）
DateTime转Unix时间戳（毫秒级）的正确姿势
毫秒级本质就是秒级 × 1000，但不能简单乘完再强转——double 乘法可能引入浮点误差，导致最后几位数字不准。
推荐写法：new DateTimeOffset(dt).ToUnixTimeMilliseconds()。它内部用整数运算，安全可靠。
- 传入
DateTime时，DateTimeOffset构造函数会按Kind自动处理时区：若为Local，自动转 UTC；若为Utc，直接使用；若为Unspecified，默认按本地时区解释（这点容易被忽略） - 想彻底规避歧义？统一用
DateTimeOffset类型接收和传递时间，比DateTime更明确 - 旧项目还在用 .NET Framework 4.6 以下？得手动算：先转 UTC，再用
(dt.Ticks - DateTimeOffset.UnixEpoch.Ticks) / TimeSpan.TicksPerMillisecond
从时间戳反解 DateTime 容易踩的坑
用 DateTimeOffset.FromUnixTimeSeconds() 或 .FromUnixTimeMilliseconds() 得到的是 DateTimeOffset，不是 DateTime。直接取 .DateTime 属性会丢失时区偏移信息，且返回值 Kind 是 Unspecified。
- 需要
DateTime就显式调用.UtcDateTime（获取 UTC 时间）或.LocalDateTime（获取本地等效时间） - 如果后续要序列化为 JSON，
DateTimeOffset默认输出带时区（如"2024-05-20T08:30:00+08:00"），而DateTime取决于Kind，可能变成"2024-05-20T08:30:00"丢失上下文 - 别用
DateTime.AddSeconds()手动加——UnixEpoch是DateTimeOffset，不是DateTime，类型不匹配会绕晕自己
跨平台时间戳交互要注意什么
和 JavaScript、Python、Go 互传时间戳时，核心矛盾只有一个：它们默认都用毫秒，而 C# 的 ToUnixTimeSeconds() 是秒——混用必出错。
- 前端
Date.now()返回毫秒，后端收到后别直接喂给FromUnixTimeSeconds()，否则时间变成 1970 年 - API 设计阶段就约定单位：JSON 字段名带后缀更安全，比如
created_at_ms或expires_at_s - 数据库存时间戳？PostgreSQL 的
bigint存毫秒没问题，SQL Server 的datetime2建议存DateTimeOffset，别存原始数字——可读性和时区处理成本低得多
时间戳本身没时区，但它的“含义”取决于你用什么单位、在哪一步做了时区转换。错一次，排查半天。
