应在模型的 afterSave() 钩子中统一用 inc() 原子更新 tag_freq 字段，避免控制器分散处理；排序需用 orderRaw() 或 field() 处理加权表达式；高并发下应单例封装 Db 操作；withCount() 与 inc() 语义不同，前者去重后者计行为，不可混用。
ThinkPHP 模型里怎么给标签字段加频次统计逻辑
直接在模型的 save() 或 update() 阶段手动更新频次字段，别依赖数据库触发器或外部脚本——TP 的事务和钩子机制足够稳，也更可控。
常见错误是把频次更新写在控制器里，结果漏掉批量操作、API 调用、命令行任务等非 Web 入口场景，导致统计断层。正确做法是统一收口到模型的 afterSave() 钩子中。
- 确保模型启用了事件支持：在模型类顶部加
use think\model\Event;，并在initialize()中注册self::event('after_write', [...]); - 频次字段（比如
tag_freq）必须是独立字段，不能和标签内容混在 JSON 字段里——否则无法走索引、无法原子更新 - 使用
$this->where('tag_name', $this->tag_name)->inc('tag_freq')->update();而不是先查再改，避免并发覆盖
热门标签加权排序时，为什么 order() 直接写 tag_freq * weight 不生效
因为 ThinkPHP 的 order() 默认只接受字段名或原始 SQL 片段，而 tag_freq * weight 属于表达式，不加包裹会被当成字符串字面量处理，最终生成的 SQL 是 ORDER BY 'tag_freq * weight'，而非计算值。
真实场景下，权重 weight 可能来自配置、用户行为衰减系数或时间衰减因子，硬编码进 SQL 容易失控。
立即学习“PHP免费学习笔记（深入）”；
- 必须用
orderRaw()：例如$model->orderRaw('tag_freq * {weight} DESC', ['weight' => $dynamic_weight]) - 如果权重随时间变化（如 24 小时内热度加权），建议提前算好临时字段，用
field('*, tag_freq * ? AS score', [$weight])再order('score', 'desc') - MySQL 8.0+ 可用窗口函数做分组归一化，但 TP6 默认不支持复杂窗口表达式，需手写
query()原生语句
标签频次统计遇上高并发写入，inc() 为啥还是丢数据
inc() 底层确实是 UPDATE ... SET x = x + 1，但前提是它走的是同一个模型实例、同一张表、且没被事务隔离级别干扰。实际踩坑最多的是「多模型操作同一标签表」或「跨库/跨连接更新」。
比如文章模型 A 和评论模型 B 都调用同一个标签统计逻辑，但各自 new 了不同模型类，缓存或连接池没共享，就可能产生竞态。
- 统一用单例模式封装标签统计服务：定义
TagCounter::inc($tagName)，内部强制复用一个Db::name('tag_stats')连接 - 避免在事务外调用
inc()后立刻读取——MySQL 默认 RR 隔离下，其他事务看不到未提交的变更，看起来像“没加” - 线上压测发现频次增长慢于请求量？检查是否开启了
debug模式，TP 的日志收集会阻塞主流程，尤其在高频afterSave中
为什么用 withCount() 统计标签关联数，结果和手动 inc() 频次对不上
因为 withCount() 查的是「当前关联关系数量」，比如某标签被多少篇文章绑定；而手动 inc() 统计的是「被使用的次数」，比如同一篇文章多次编辑、反复打同一个标签，也会重复累加。
这不是 bug，是设计意图差异：前者适合做「去重热度」，后者适合做「行为热度」。选错会导致推荐结果偏冷启动或过度马太效应。
- 需要去重统计，就用
withCount('articles')+ 缓存聚合视图（MySQL 的CREATE VIEW或 Redis HyperLogLog） - 需要行为频次，就坚持用
inc()，但记得在标签解绑时补dec()，否则数据漂移 - 两者混合加权？别在 SQL 里硬拼，先查出
withCount结果，再用 PHP 补上行为分，避免 JOIN 爆表
最麻烦的是时间衰减——频次数字本身没时间戳，加权时得额外维护 last_active_time 字段，不然昨天的爆款和今天的冷门全挤在一起排序，权重就失真了。
