Db::lockUpdate() 是 ThinkPHP 中最稳妥的时段库存防超卖方式，需在事务中配合明确 WHERE 条件使用，确保查询、判断、扣减、写入原子执行，避免表锁与耗时操作。
预约时段库存怎么用 Db::lockUpdate() 防超卖
直接上锁查改是 ThinkPHP 里最稳妥的时段库存控制方式，Db::lockUpdate() 能避免并发下单导致同一时段被重复占用。它本质是执行 SELECT ... FOR UPDATE，只在事务中生效，且必须搭配 Db::transaction() 使用。
常见错误是没开事务就调用 lockUpdate()，结果锁根本不起作用；或者锁了行但没做库存判断就提交，等于白锁。
- 务必把查询、判断、扣减、写记录全部包进同一个事务块里
- 锁查询时要带上明确的 WHERE 条件（比如
where('time_slot', '09:00-10:00')->where('date', '2024-06-15')），否则可能锁整张表 - 不要在锁查询后做耗时操作（如发短信、调外部 API），会延长锁持有时间，拖慢并发性能
- 如果时段表有联合唯一索引（
date + time_slot），锁效率更高；没索引时 MySQL 可能升级为表锁
think\queue\Job 怎么清理过期排队号
用户预约成功后生成排队号，但没在规定时间内完成支付或确认，这个号就得自动释放，否则会卡住后续用户的预约位置。不能靠前端定时轮询，得用队列异步处理。
ThinkPHP 自带的队列组件支持延迟任务，关键在于：不是“到期删”，而是“到期检查+释放”。因为释放动作本身要更新数据库、通知下游、可能还要重排队列顺序。
立即学习“PHP免费学习笔记（深入）”；
- 投递任务时用
->delay(1800)（例如 30 分钟后执行），参数是秒数 - Job 类的
handle()方法里先查该排队号当前状态，只有状态为pending才执行释放逻辑 - 释放时除了更新
status字段，建议同时写一条日志记录（如expired_release类型），方便对账 - 别在 Job 里直接调
Db::delete()物理删除排队记录——历史数据要留痕，至少保留 90 天
怎么用 whereTime() 和 group() 统计每日各时段占用率
运营需要看哪些时段总被约满、哪些长期空闲，就得按天+时段聚合统计。ThinkPHP 的 whereTime() 比手写 WHERE date BETWEEN 更安全（自动处理时区和格式），配合 group() 可以一行写出清晰聚合逻辑。
容易踩的坑是没对 time_slot 做标准化——比如 “9:00-10:00” 和 “09:00-10:00” 被当成两个不同值，导致分组不准。
- 查询前统一用
str_pad()补零，确保所有时段字符串格式一致（如substr($t, 0, 2).':00-'.substr($t, 3, 2).':00'） - 用
whereTime('create_time', 'today')查当天数据，用whereTime('create_time', '-7 days', 'now')查近一周 - 聚合时用
count('*') as used和关联时段总容量表做左连接，才能算出真实占用率 - 别在 PHP 层循环查每个时段——100 个时段就发 100 次 SQL，应该用单条 SQL +
GROUP BY date, time_slot
为什么 validateScene() 校验预约时间总失败
校验失败往往不是规则写错了，而是时间字段类型不匹配。ThinkPHP 的验证器默认把传入的 time_slot 当字符串处理，但如果你数据库字段是 TIME 或 ENUM，或者前端传的是带秒的 "09:00:00"，而规则只写了 in:09:00-10:00,10:00-11:00，就会直接不通过。
- 验证场景里优先用
regex而不是in，比如/^([0-1]\d|2[0-3]):[0-5]\d-([0-1]\d|2[0-3]):[0-5]\d$/先保格式合法 - 如果时段来自下拉选，后端验证仍要查库确认该时段当天是否开放（
is_open = 1且remain > 0），不能只信前端传的值 -
require|date对2024-06-15有效，但对15/06/2024就失效——统一要求前端传Y-m-d格式 - 注意时区：服务器设的
date_default_timezone_set('Asia/Shanghai')必须和数据库TIMESTAMP字段行为一致，否则today判断会偏移
时段库存不是单纯数字增减，它绑着时间维度、业务规则、并发边界和用户感知。哪怕加个「可预约截止时间」配置项，漏掉对 strtotime('+2 hours') 和系统当前时间的比对，整个排队逻辑就可能在午夜失效。
