DateTime.Subtract() 返回 TimeSpan 而非 DateTime，表示时间跨度而非时间点；TimeSpan.Days 仅取整数天部分，TotalDays 才返回带小数的总天数；格式化 TimeSpan 应避免 ToString("d")；跨时区计算需统一使用 Utc 或 Local Kind。
DateTime.Subtract() 返回 TimeSpan，不是 DateTime
很多人以为 DateTime.Subtract() 会返回另一个 DateTime，结果发现类型是 TimeSpan——这直接导致后续调用 .ToString() 或赋值给 DateTime 变量时报错。本质是：日期差不是“时间点”，而是“时间跨度”。
-
DateTime表示某个具体时刻（如 2024-05-20 14:30:00） -
TimeSpan表示两个时刻之间的间隔（如 3 天 2 小时 15 分） - 错误写法：
DateTime diff = dt1.Subtract(dt2);→ 编译失败 - 正确写法：
TimeSpan diff = dt1.Subtract(dt2);或更常用：dt1 - dt2
TimeSpan.TotalDays 和 TimeSpan.Days 完全不同
计算天数时最容易踩坑：用 TimeSpan.Days 得到的是“整数天部分”，而 TimeSpan.TotalDays 才是带小数的总天数（比如 2.75 天）。如果要做精确比较或参与浮点运算，必须用 TotalXxx 系列属性。
-
TimeSpan.Days：只取天字段，忽略小时/分钟/秒（如 36h →Days == 1） -
TimeSpan.TotalDays：换算成 double，36h →TotalDays == 1.5 - 同理：
TotalHoursvsHours、TotalMinutesvsMinutes - 场景举例：判断是否超过 72 小时 → 用
ts.TotalHours > 72，别用ts.Hours > 72（永远为 false）
ToString("d") 不是“天数格式化”，而是短日期模式
想把 TimeSpan 输出成 “3天2小时” 这种中文描述？别碰 ToString("d") ——它对 TimeSpan 无效，而且在 DateTime 上也只表示“短日期”（如 5/20/2024），跟“天”毫无关系。
-
TimeSpan的标准格式字符串只有"c"（规范）、"g"（紧凑）、"G"（长） - 要输出“3天2小时”，得手动拼：
$"{ts.Days}天{ts.Hours}小时{ts.Minutes}分" - 注意负数：
ts.Days对负的TimeSpan是负值，但ts.Hours始终非负（它只取当前天内的小时）→ 更稳妥用ts.Duration().Days配合ts.Sign
DateTime.Now 和 DateTime.UtcNow 混用会导致跨时区计算错误
在服务器上做时间差计算时，如果一个时间用 DateTime.Now（本地时区），另一个用 DateTime.UtcNow（UTC），相减结果可能偏差数小时，且不可预测。
- 所有参与计算的
DateTime必须统一 Kind：DateTimeKind.Utc或DateTimeKind.Local - 推荐做法：入库和计算全部用 UTC，显示时再转本地 ——
DateTime.UtcNow+TimeZoneInfo.ConvertTimeFromUtc() - 检查 Kind：
dt.Kind == DateTimeKind.Unspecified时，Subtract()仍能运行，但语义模糊，容易出错 - 转换建议：
dt.ToUniversalTime()（不推荐，会按本地时区解释Unspecified）→ 改用DateTime.SpecifyKind(dt, DateTimeKind.Utc)
实际业务里最常被忽略的是 DateTime.Kind 的隐式传播和 TimeSpan 字段的截断特性——它们不会报错，但会在某次跨月或夏令时切换后突然暴露逻辑偏差。
