应在数据库层实时计算权重分，如mysql中用field()拼接表达式实现点击量与时间衰减的动态打分，避免php层循环计算或预存字段定时更新。
ThinkPHP 模型里怎么实时算权重分，别用数据库排序
直接在模型查询时靠 order() 排序字段（比如 weight）根本没用——那只是静态值。真要结合点击量、发布时间动态打分，得把计算逻辑放进查询本身，而不是依赖预存字段。
常见错误是：先查出所有数据，再用 PHP 循环算分、usort() 排序。这会导致全表扫描 + PHP 层压力大，10 万条记录就卡死。
正确做法是让数据库承担计算：用 Db::query() 或模型的 field() + order() 拼接表达式。MySQL 支持运行时计算列，ThinkPHP 5.1+ 和 6.x 都能透传。
- ThinkPHP 6 推荐用
withField()或原生 SQL 字段表达式：Db::name('article')->field('*, (click * 0.7 + POW(UNIX_TIMESTAMP(NOW()) - UNIX_TIMESTAMP(create_time), 0.3)) AS weight') - TP5.1 要用
field()+order()组合：->field('*, (click * 0.7 + LOG(10, 1 + UNIX_TIMESTAMP() - UNIX_TIMESTAMP(create_time))) AS weight')->order('weight DESC') - 注意
UNIX_TIMESTAMP()在 MySQL 里返回秒级时间戳，别错用NOW()直接拼字符串；TP 会自动转义，但函数名必须写对
为什么不能把权重存在字段里定时更新
存成字段看似省事，实际埋雷：一旦点击量突增或有新热点，缓存未刷新前排序就失真；定时任务还可能撞上高峰写入，拖慢主库。
更麻烦的是「时间衰减」部分——每秒权重都在变，你不可能每秒都 UPDATE 全表。哪怕加索引，UPDATE ... WHERE create_time > 'xxx' 在大数据量下也是锁表风险。
- 实时性要求高的场景（如热搜榜、推荐流），必须放弃「预计算 + 存库」思路
- 如果真要落库，只适合低频更新（如每天凌晨跑一次），且得加
weight_updated_at字段做兜底判断 - TP 的
saveAll()批量更新不适用于这种动态场景，容易触发重复计算或事务超时
点击量怎么安全累加又不影响排序性能
直接 $model->where(...)->setInc('click') 是对的，但别在同一个请求里边查边算权重——查的时候 click 还是旧值，等 setInc 完再查一遍？那多一次 IO。
关键是：权重计算和点击更新必须解耦。点击归点击，用原子操作快速完成；排序归排序，走纯读 SQL，不依赖刚更新的值。
- 用
Db::execute("UPDATE think_article SET click = click + 1 WHERE id = ?")更轻量，绕过模型事件和验证 - 别在
setInc()后立刻select()，除非加了LOCK IN SHARE MODE（TP 不原生支持，得手写） - 如果业务允许小误差，可以前端用 Redis
INCR计数，异步写回 DB，避免数据库写竞争
TP6 中使用 withAttr 处理权重显示但不参与排序？
不行。withAttr 是模型读取后对字段做格式化（比如把 status 0/1 转成中文），它发生在 PHP 层、SQL 执行完之后，完全不参与 ORDER BY。
有人试过在 getWeightAttr 里写计算逻辑，结果发现排序还是按原始字段来——因为数据库根本不知道这个 attr。
-
withAttr只影响最终输出的数组结构，不影响查询过程 - 想让 PHP 算分再排，只能用
collection()->sortByDesc()，但仅限于数据量小（ - TP6.3+ 的
scope也不能替代字段表达式，scope 只能拼where，不能插field表达式
真正要兼顾性能和动态性，就得接受「SQL 里写公式」这件事。别嫌它不够“优雅”，线上扛不住的时候，优雅不顶内存。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
