判断时间段重叠的核心逻辑是：不重叠当且仅当 startA ≥ endB 或 startB ≥ endA；否则必有交集，需统一用 DateTime 比较、校验有效性、明确端点处理、防范时区与精度误差。
判断两个时间段是否重叠的通用逻辑
核心就一条：两个时间段不重叠，当且仅当 startA >= endB 或 startB >= endA；反过来，只要这两个条件都不成立，就一定有交集。
别用“中间点是否在另一个区间内”这种思路——它漏掉边界相接（如 [10:00, 11:00] 和 [11:00, 12:00]）或完全嵌套（如 [10:30, 11:30] 包在 [10:00, 12:00] 里）的情况。
实操建议：
- 统一用
DateTime比较，避免字符串解析引入时区或格式歧义 - 明确包含/排除端点：业务上
11:00算不算冲突？如果算，用和 <code>>=；如果不算（仅开区间），才用和 <code>> - 永远先校验
start ，否则 <code>TimeSpan.Negate()式错误会悄悄污染结果
C# 中用 DateTime 写一个安全的交集判断函数
直接封装成静态方法最稳妥，避免每次手写逻辑出错。关键不是“怎么写”，而是“怎么防错”。
示例：
public static bool HasOverlap(DateTime start1, DateTime end1, DateTime start2, DateTime end2)
{
if (start1 > end1 || start2 > end2) throw new ArgumentException("Invalid time range: start must not be after end");
<pre class="brush:php;toolbar:false;">// 闭区间：端点重合即视为冲突（如会议结束和下一场开始同为 14:00）
return !(end1 < start2 || end2 < start1);}
注意点：
- 参数顺序不重要，但命名必须清晰（
start1/end1和start2/end2不要混成from/to这种模糊名） - 没做
Nullable<datetime></datetime>处理？那调用前必须确保非空，否则NullReferenceException会在比较时爆发，而不是在入口处 - 如果涉及跨天（如夜班 22:00–06:00），这个函数会误判——它默认所有时间在同一自然日内，需额外归一化处理
数据库查重场景下，为什么不能只靠 C# 判断
当你要查“用户已预约的时间段是否和新申请冲突”，把全部历史记录读到内存再逐个比对，是典型性能陷阱。
应该让数据库干这事：
- SQL Server 用
WHERE NOT (end @newEnd)，配合start和end字段上的复合索引 - EF Core 中别写
.Where(x => HasOverlap(...))，这会触发客户端求值（ClientEval），全表拉到内存 - 用原始 SQL 或 EF.Functions.Overlaps（.NET 7+）才能下推到服务端
- 注意数据库时区：如果
DateTimeKind.Unspecified存入，查询时可能因本地时区偏移导致边界错位
容易被忽略的边界：时区、精度、默认值
看似简单的比较，崩坏往往发生在毫秒级或跨时区场景。
常见翻车点：
-
DateTime.Now返回的是本地时区，而数据库字段可能是UTC；直接比较等于拿苹果和橙子比 -
DateTime.Parse("2024-01-01")默认DateTimeKind.Unspecified，参与比较时行为取决于上下文（比如ToUniversalTime()会按本地时区转，可能偏差数小时） - SQL Server 的
datetime类型精度只有 3.33ms，而 .NETDateTime是 100ns；用==比较可能因截断失败，应改用>=/配合小容差（如 <code>TimeSpan.FromMilliseconds(1)） - 前端传来的
"2024-01-01"可能被 JS 解析成 UTC 零点，后端收到却是本地时间零点——前后端时间语义不一致，比逻辑本身更难调试
真正麻烦的从来不是“怎么写判断”，而是“怎么让所有环节对时间的理解完全一致”。
