Yii预约系统冲突校验需主动计算时间重叠：定义start_time/end_time/resource_id等字段，用isConflict()方法在beforeValidate中检测重叠，控制器调用并添加validateNoConflict规则，辅以复合索引、行锁和UTC存储优化。
在 Yii 框架中实现预约系统的冲突校验，核心在于准确获取已有预约时段、合理建模时间范围、并在保存前完成逻辑判断。不能只靠数据库唯一索引（如组合字段），因为时间重叠是区间关系，需主动计算。
一、定义清晰的时间模型字段
确保预约记录表（如 appointment）至少包含：
- start_time：开始时间（datetime 或 int 时间戳，推荐 datetime，便于查询和时区处理）
- end_time：结束时间（同上，且必须 ≥ start_time）
- resource_id（可选但推荐）：被预约的资源 ID（如医生 ID、会议室 ID），用于隔离不同资源间的冲突
- status（可选）：状态字段（如 pending/approved/cancelled），校验时应排除已取消或无效记录
二、编写冲突检测逻辑（推荐放在 Model 的 beforeSave 或自定义验证方法中）
以 Appointment 模型为例，在 beforeValidate() 或新增一个 isConflict() 方法中实现：
public function isConflict()
{
if (!$this->start_time || !$this->end_time) {
return false;
}
$query = self::find()
->where(['resource_id' => $this->resource_id])
->andWhere(['!=', 'status', 'cancelled']) // 排除已取消
->andWhere([
'AND',
['<=', 'start_time', $this->end_time], // 已有记录开始时间 ≤ 当前结束时间
['>=', 'end_time', $this->start_time], // 已有记录结束时间 ≥ 当前开始时间
]);
// 如果是更新操作，排除自身
if ($this->getIsDirty('start_time') || $this->getIsDirty('end_time') || $this->getIsDirty('resource_id')) {
$query->andWhere(['!=', 'id', $this->id]);
}
return $query->exists();
}
该逻辑覆盖所有重叠情形（完全包含、部分交叉、边界相接）。注意：Yii 2.0+ 支持 getIsDirty() 判断字段是否修改；若用 Yii 1.1，可用 $this->isNewRecord === false 并手动比对原始值。
三、在控制器中调用并响应冲突
不要仅依赖前端校验，后端必须拦截：
public function actionCreate()
{
$model = new Appointment();
if ($model->load(Yii::$app->request->post())) {
if ($model->isConflict()) {
$model->addError('start_time', '该时间段已被占用，请选择其他时间');
} elseif ($model->save()) {
return $this->redirect(['view', 'id' => $model->id]);
}
}
return $this->render('create', ['model' => $model]);
}
建议同时在 rules() 中添加自定义验证规则，让错误统一显示在对应字段下：
// 在 Appointment::rules() 中
[['start_time', 'end_time'], 'validateNoConflict'],
// 对应方法
public function validateNoConflict($attribute, $params)
{
if ($this->isConflict()) {
$this->addError($attribute, '所选时间段与其他预约冲突');
}
}
四、进阶优化点
-
数据库索引优化：为
(resource_id, status, start_time, end_time)建复合索引，加速冲突查询 -
并发安全：高并发场景下，可加数据库行锁（如
SELECT ... FOR UPDATE），或使用事务 + 冲突重试机制 - 粒度控制：若业务要求“30 分钟一档”，可在保存前将时间自动对齐（如向下取整到最近 30 分钟），避免微小偏差导致误判
- 跨天支持：上述逻辑天然支持跨天（如 22:00–02:00），无需额外处理
不复杂但容易忽略的是时间字段类型一致性与时区处理——务必统一使用 UTC 存储，前端展示时再转本地时间，否则夏令时或跨时区预约会出错。
