应直接用 datetime.compare 或 >、

直接用 DateTime.Compare 或比较运算符（>、）就行，别转字符串、别拼格式、别自己写逻辑判断年月日。

用 DateTime.Compare 判断大小关系最稳妥

这个函数返回 -1、0、1，分别代表“小于”“等于”“大于”，不依赖本地时区或文化习惯，语义清晰，适合做分支判断。

• 常见错误：把 DateTime 转成 string 再用 string.CompareTo —— 格式一变就错，比如 "2023/1/1" 和 "2023/10/1" 字符串比较结果是错的
• 使用场景：排序、条件跳转、校验时间范围（如“不能早于当前时间”）
• 参数差异：两个 DateTime 值都必须是有效值；如果可能为 null，得先判空，或改用 Nullable<datetime></datetime> + 空合并逻辑
• 示例：int result = DateTime.Compare(time1, time2); if (result

>、 运算符足够直观，但要注意精度和时区

C# 的 DateTime 支持直接用比较符，可读性高，但背后隐含两个关键点：精度截断和 Kind 属性。

C#

"避开 C# 常见错误——空陷阱、异步陷阱、LINQ 陷阱及资源泄漏。"

下载

• 常见错误：比较 DateTime.Now 和一个从数据库读出的 datetime2 字段，发现有时差——因为前者是 Local，后者可能是 Unspecified，CompareTo 内部按 UTC 对齐时行为不一致
• 使用场景：简单逻辑判断，如 if (deadline
• 性能影响：几乎无开销，比调用方法略快，但差别可忽略
• 建议：统一用 DateTimeKind.Utc 存储和比较，或显式调用 .ToUniversalTime() 对齐后再比

别用 ToString + Parse 做比较

这是新手最容易掉进去的坑：为了“看得懂”把时间转成字符串再比，结果引入格式依赖、文化敏感、性能损耗三重风险。

• 错误现象：DateTime.Parse("2023-01-02").ToString("yyyy-MM-dd") == DateTime.Parse("2023-1-2").ToString("yyyy-MM-dd") 表面看相等，但只要换一个 CultureInfo，Parse 就可能失败或解析错
• 兼容性影响：在服务器部署时若系统区域设置不同（比如美国 vs 中国），Parse 行为会变
• 正确做法：保持 DateTime 类型贯穿整个流程，只在展示层才格式化
• 例外情况：仅当你确定两个字符串来自同一来源、固定格式、且无法获取原始 DateTime 对象时，才考虑用 DateTime.TryParseExact 先转回类型再比

真正麻烦的是跨时区场景——DateTime.Kind 不匹配时，Compare 和运算符的行为会静默不同，不是报错，而是结果不符合直觉。这点很容易被忽略，尤其在处理 Web API 返回的时间或 SQL Server 的 datetimeoffset 时。