thinkphp 的 setinc/setdec 高并发下易出错，因非原子操作、缓存不同步、事务边界不清；须用全新查询构造器调用，字段类型为 int/bigint 且设默认值0，禁用 setlazyinc，更新后及时清缓存并加二级排序与索引。
ThinkPHP 的 setInc 和 setDec 看似简单，但直接拿来就用，高并发下大概率出错、数据不准、缓存不同步——核心问题不在方法本身，而在调用时机、事务边界和缓存协同。
为什么不能在 save() 后手动 $model->hot++ 再 save()
这种写法本质是“读-改-写”三步，在 PHP 层做加法，不是原子操作：
- 并发请求同时读到
hot=10，各自加 1 后都写回11，实际应为12 -
$model->save(['hot' => $model->hot + 1])会覆盖其他字段，除非你显式传入全部要更新的字段 - 若模型启用了自动时间戳或事件钩子，
save()可能触发额外逻辑，干扰统计意图
setInc / setDec 必须配合 where 使用，且不能复用模型实例
这两个方法不接受条件参数，只作用于当前已设置的查询条件。常见陷阱是模型对象被复用：
- 错误写法：
$tag = TagModel::find(123); $tag->where('status', 1)->setInc('hot');—— 这里where('status', 1)是冗余且危险的，主键查单条不该加额外条件；更糟的是，如果后续用同一个$tag实例查列表，where条件会被合并残留 - 正确姿势：用全新查询构造器，如
TagModel::where('id', 123)->setInc('hot')或Db::name('tag')->where('id', 123)->inc('hot')->update() - 字段类型必须是
INT或BIGINT；若为NULL，部分 ThinkPHP 版本调用setInc会报错，建表时设默认值DEFAULT 0
延迟更新（setLazyInc）是个坑，别在关键路径用
ThinkPHP 提供了带延迟参数的 setLazyInc('field', 1, 60)，但它依赖内存缓存暂存 SQL，不适用于生产环境的计数场景：
- 延迟期间进程重启或 FPM worker 释放，计数直接丢失
- 同一模型对象后续调用
select()时，延迟更新残留的where条件会被合并进新查询，导致 SQL 错误（比如WHERE id=5 AND status=0被插进列表页查询） - 没有失败重试机制，网络抖动或 DB 拒绝连接时，计数静默失败
- 真要异步，应走消息队列 + 独立消费进程，而不是靠框架级延迟
热度排序加 LIMIT 时，order('hot desc') 不够用
只按 hot 排序再 limit 10，同热度标签会被随机截断，分页结果不稳定：
- 必须补二级排序，例如
order('hot desc, id desc')或order('hot desc, updated_time desc') -
hot字段务必加索引：ALTER TABLE `tag` ADD INDEX idx_hot (hot); - 若热度更新频繁，建议建联合索引
idx_hot_id (hot, id)，避免排序时回表 - 缓存该结果时，别缓存整个数组，而是用
cache('top_tags_v2', $data, 300)显式设 5 分钟过期，并在每次setInc后清掉这个 key
最易被忽略的一点：setInc 是 DB 层原子操作，但缓存读取是另一条路径。更新后不清缓存，前端永远看不到新热度；清缓存时没考虑分布式部署下的多节点一致性，又会导致短暂不一致。这三步——DB 自增、删缓存、补二级排序——少走一步，线上就出数据毛刺。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
