推荐用 DateOnly 判断是否为同一天，它只存年月日、无时区和时间干扰；DateTime.Date 虽快但易受时区和 DateTimeKind.Unspecified 影响。
用 DateOnly 判断是否为同一天最干净
直接比 DateTime.Date 也能行，但容易漏掉时区或默认值陷阱。.NET 6+ 推荐用 DateOnly —— 它天生只存年月日，不带时间、不涉时区，语义清晰，也不怕 DateTime 默认值（比如 DateTime.MinValue）干扰。
- 如果两个
DateTime变量是本地时间且确定无跨时区场景，dt1.Date == dt2.Date最快，但要注意：若其中一个是DateTimeKind.Unspecified，和 UTC 时间混用时可能出错 - 想彻底规避时区/精度干扰，先转成
DateOnly：DateOnly.FromDateTime(dt1) == DateOnly.FromDateTime(dt2) -
DateOnly不支持null，传入null的DateTime?会抛ArgumentNullException，得先判空
比较时间部分（时分秒毫秒）别用 ToString 截字符串
有人把 DateTime 格式化成 "HH:mm:ss" 再比字符串，看似简单，实则埋雷：格式依赖线程当前文化（en-US 下 13:05:00，zh-CN 下可能变 下午01:05:00），还丢了毫秒精度。
- 正确做法是提取时间组件相减：
dt1.TimeOfDay == dt2.TimeOfDay——TimeOfDay返回TimeSpan，直接比值，稳定又高效 - 如果只要“小时和分钟”相同（忽略秒和毫秒），用：
dt1.Hour == dt2.Hour && dt1.Minute == dt2.Minute - 注意
TimeOfDay是基于DateTime的本地时间值，若原始时间是 UTC，先调用ToLocalTime()或统一转 UTC 再比，否则逻辑错位
DateTime.Compare 和运算符重载不是万能的
很多人以为 DateTime.Compare(dt1, dt2) == 0 就等于“同一天”，其实它比的是完整时间戳（含时分秒毫秒），和 dt1 == dt2 效果一样，不是日期级比较。
- 它适合判断“哪个时间更早”，不适合“是否同一天”或“是否同一时刻（忽略毫秒）”
- 若想忽略毫秒只比到秒级，得手动归一化：
new DateTime(dt1.Year, dt1.Month, dt1.Day, dt1.Hour, dt1.Minute, dt1.Second) == new DateTime(dt2.Year, dt2.Month, dt2.Day, dt2.Hour, dt2.Minute, dt2.Second) - 频繁做这种归一化建议封装成扩展方法，避免重复写长构造函数
跨时区比较前必须明确“同一天”的定义
用户问“是否同一天”，但没说按哪个时区算——北京早上 8 点和纽约晚上 8 点是同一秒，但日期差一天。这时候硬比 Date 属性会出错。
- 如果业务要求“用户本地看到的日期相同”，就用各自
.Date或DateOnly.FromDateTime() - 如果要求“UTC 下是同一天”，统一转
dt.ToUniversalTime().Date再比 - 千万别用
dt1.Kind == DateTimeKind.Utc && dt2.Kind == DateTimeKind.Utc就默认可直比——DateTime的Kind只是标记，不保证值本身真符合该时区，需人工校验或用TimeZoneInfo.ConvertTime
时区和精度是这类比较里最容易被跳过的两层，写完记得问自己一句：这个“同一天”，对谁而言？在什么上下文里成立？
