如何在ThinkPHP中实现字段自增自减_inc与dec延迟更新机制解析-ThinkPHP-PHP中文网

thinkphp 的 inc()/dec() 不立即生效，因仅预编译表达式并存入 set 数组，需调用 save()/update()/setinc() 等触发方法才执行 sql；若模型无有效主键或事务中遗漏 save()，更新将静默失败。

如何在thinkphp中实现字段自增自减_inc与dec延迟更新机制解析

ThinkPHP 的 `inc()` 和 `dec()` 为什么不是立刻生效？

因为它们默认不执行 SQL，只做表达式预编译。调用 inc('score') 后，TP 并没发 UPDATE 请求，而是把 score = score + 1 存进待执行的 set 数组里，等真正调用 save()、update() 或 setInc() 这类触发方法时才拼 SQL 发出去。

常见错误现象：$user->inc('login_count')->save(); 看似连贯，但若模型没主键或主键没设好，save() 会静默失败，字段根本没变；更隐蔽的是在事务里多次调用 inc() 却忘了最后 save()，结果全丢进黑洞。

必须确保模型已绑定有效主键（$pk 已定义且数据中存在），否则 save() 无法生成 WHERE 条件
不要混用 inc() 和手动赋值：比如先 $model->score = 100，再 $model->inc('score')，后者会覆盖前者，最终只执行自增
批量操作慎用：在循环里反复 inc() + save() 是 N 次查询；应改用 Db::table()->where()->inc('field')->update() 一次完成

想延迟更新但又不想依赖模型实例？用 `Db::raw()` + `update()`

当你要绕过模型层、直接对某条记录做原子自增，又希望逻辑清晰可复用，Db::raw() 是最稳的选择。它把表达式原样塞进 SQL，不经过模型属性映射，也不存在“忘记 save”的问题。

使用场景：计数器更新、库存扣减、积分变动等强调原子性和可控时机的操作。

示例：

Db::name('user')->where('id', 123)->update([
    'score' => Db::raw('score + 10'),
    'updated_at' => time()
]);

Db::raw('score + 10') 不会被转义或拼接，直接参与 SET 字段生成
注意字段名大小写：MySQL 默认不区分，但开启 lower_case_table_names=0 时，字段名需严格匹配建表定义
不能用 Db::raw() 做条件判断，比如 where('score', '>', Db::raw('limit')) 在 TP6.0+ 是支持的，但老版本可能报错，建议统一用 whereRaw()

`setInc()` 和 `setDec()` 与模型 `inc()` 的关键区别

setInc() 是 Db 类的静态方法，不依赖模型实例，也不走模型事件和验证，属于“裸 SQL 包装层”。而模型上的 inc() 是实例方法，会触发 before_write 等钩子，也会受自动时间戳、类型转换影响。

性能差异不大，但兼容性很不同：模型 inc() 在 TP5.1 中要求必须先查出数据（否则无主键），而 setInc() 从 TP5.0 就支持纯条件更新。

推荐在无需业务逻辑干预时优先用 Db::name('table')->where(...)->setInc('field', 1)
setInc('field', 0) 是合法的，但实际无意义；传负数如 -5 等价于 dec('field', 5)，但语义混乱，别这么写
TP6.0+ 中 setInc() 支持多字段，如 setInc(['view_count' => 1, 'last_view_time' => time()])，但第二个字段不会被当表达式处理，只是普通赋值

并发下自增不安全？别指望 `inc()` 自带锁

ThinkPHP 所有自增方法都不自动加数据库行锁。如果两个请求几乎同时执行 inc('stock')，可能出现“读-改-写”竞态，导致少减 1。

这不是 TP 的 bug，是所有 ORM 的共性限制。真实业务中，库存、余额这类字段必须靠数据库原生命令保障原子性。

正确做法是用 Db::raw('stock - 1') 配合 WHERE 条件做乐观锁：where('stock', '>=', 1)，再检查影响行数是否为 1
高并发场景下，考虑用 Redis 做预减（decrby），成功后再落库，避免 DB 成瓶颈
MySQL 的 UPDATE ... SET stock = stock - 1 WHERE id = 1 AND stock >= 1 是唯一可靠方案，TP 的 setDec() 只负责生成这部分 SQL，WHERE 还得你手动加

很多人卡在“为什么我用了 inc 却还是超卖”，答案就在这里：TP 不解决并发控制，它只负责把你的意图翻译成 SQL —— 而那条 SQL 本身是否安全，得你来设计。