Luxon 空区间放在范围中间，overlaps 却返回 true

一个有效区间从5点到8点，另一个区间起止都是6点。后者不包含任何时刻，Luxon 的 overlaps 却返回 true；换成5点或8点的零长度区间，结果又变成 false。

在正式Luxon3.7.2中，overlaps只检查 this.e > other.s && this.s < other.e。位于内部的零长度端点能同时满足这两个比较，方法没有先排除空区间。

先决定零长度在业务里代表什么

半开时间范围通常包含起点、不包含终点。起止相同的区间为空，不应与预约范围形成占用冲突。但有些应用把零长度记录当成提醒时点，这时“时点落在范围内”是另一项判断，不应借用范围重叠偷偷表达它。

下面只实现“两个有效、正长度范围是否重叠”。无效输入保留错误路径，不将它混成没有冲突：

function positiveRangeOverlap(a, b) {
  if (!a.isValid || !b.isValid) {
    throw new RangeError('Invalid interval');
  }
  return a.length('milliseconds') > 0
    && b.length('milliseconds') > 0
    && a.overlaps(b);
}

a和b应已经由调用方创建为Luxon Interval，null或其他对象还需在接口边界处理。先判断isValid也避免对无效对象调用其他未作同等防护的方法。

若业务需要提醒点位于区间内，应显式使用一个DateTime点和相应的contains规则，并确认终点是否排除。不要给空区间自动增加一毫秒，那会凭空制造占用，影响计费、日程或冲突判断。

不同区间方法不能互相代替

在同一组输入上，intersection可能没有交集，overlaps却仍返回true。这是本题要识别的不一致，不能通过改成只看返回对象是否存在就掩盖原来的契约。

Interval.merge还涉及相邻区间的合并规则。不要全局替换库的overlaps方法，假定所有依赖它的算法都只需要这一处变化。局部判断最好放在明确的业务冲突入口，保留原始区间与其他用途。

回归时将同一个空区间分别放在起点、内部和终点，两个参数顺序都检查；再覆盖真正重叠、首尾相接、完全分离和无效区间。对于半开范围，首尾相接与正长度重叠也应按约定区分。

目前核对的正式3.7.2仍只有上述端点比较，没有已核证的正式修复版本。后续升级应对同一组样例重新核对，而不是只在一条有长度的正常区间上验证。