PHP环境下单个二维码实现三次时间捕获的问题求助

看起来你碰到了多节点扫码时间更新的坑，我之前做类似的预约核销系统时也踩过差不多的问题，咱们一步步来梳理排查和解决思路：

1. 检查扫码逻辑的状态分支判断 #

这是最常见的问题——你的后端代码可能只处理了第一次扫码写入T1的逻辑，没有为后续的T2、T3添加对应的判断分支。

比如很多人一开始会写这样的错误逻辑：

// 错误示例：仅处理T1的写入
BookingRecord record = bookingDao.findByBookingNumberAndId(bookingNumber, id);
if (record.getT1() == null) {
    record.setT1(new Date());
    bookingDao.save(record);
}

正确的做法应该是按节点顺序判断当前该写入哪个时间字段：

// 正确示例：多节点状态判断
BookingRecord record = bookingDao.findByBookingNumberAndId(bookingNumber, id);
if (record.getT1() == null) {
    record.setT1(new Date());
} else if (record.getT2() == null) {
    record.setT2(new Date());
} else if (record.getT3() == null) {
    record.setT3(new Date());
}
bookingDao.save(record);

要确保每次扫码时，系统能根据当前记录的T1/T2/T3状态，自动匹配对应的时间字段写入。

2. 确保数据库更新的原子性（避免并发/重复请求问题） #

如果用户快速连续扫码，或者存在并发请求，可能会导致后续的T2/T3更新被覆盖或不生效。这时候要使用带条件的SQL更新语句，确保每次更新只针对符合当前节点状态的记录：

比如更新T2的SQL应该这样写：

UPDATE booking_table
SET T2 = NOW()
WHERE id = ? 
  AND bookingNumber = ? 
  AND T1 IS NOT NULL 
  AND T2 IS NULL;

同理，更新T3时要加上T2 IS NOT NULL AND T3 IS NULL的条件。这种方式能避免因为并发请求导致的逻辑混乱，保证每次更新都是精准匹配当前节点的。

3. 排查二维码信息解析与记录查询的有效性 #

有时候不是逻辑的问题，而是第二次、第三次扫码时，二维码的信息没有被正确解析，导致找不到对应的数据库记录，自然无法写入T2/T3。

你可以在后端接口里加日志，每次扫码时打印以下内容：

• 接收到的bookingNumber和id
• 查询到的数据库记录的T1/T2/T3状态
  通过日志就能快速判断：是不是扫码时信息解析错误，或者查询不到对应的记录。

另外，也要检查前端是否每次扫码都正确传递了二维码里的所有参数，有没有遗漏或篡改的情况。

4. 检查数据库字段的约束与类型 #

确认T2、T3字段的配置和T1一致：

• 字段类型是不是都是datetime（或对应的时间类型）？
• 有没有设置非空约束？如果T2/T3被设为NOT NULL，第一次扫码时没有写入，后续更新时可能会因为空值约束报错。
  可以查看数据库的错误日志，看有没有更新T2/T3时的报错信息，这能快速定位字段配置的问题。

5. 排查系统的状态拦截或权限限制 #

有些系统会给预约记录设置状态（比如“待第一次核销”“待第二次核销”），如果后端的拦截规则只允许“待第一次核销”的记录扫码，那后续的扫码请求就会被拦截。

你需要检查：

• 系统是否对扫码请求做了状态校验？
• 校验规则是否允许已完成T1但未完成T2的记录继续扫码？
  如果是这个问题，调整状态拦截的规则即可。

内容的提问来源于stack exchange，提问作者Clyn