情境：球迷真正缺的不是播放按钮
一个普通的比赛日可能有十余场对阵，分布在不同的时间段。多数球迷打开页面的第一诉求并不是“立刻播放”，而是“今天有什么值得看”。如果页面第一屏只有一个巨大的播放按钮，用户反而需要自己去别处确认信息。
因此，索引的价值高于入口本身。把场次、时间、热度、类型先摊开，用户才能做出选择。
冲突：信息越多，决策越慢
当索引条目从 5 条增长到 50 条，页面并没有变好用，反而变难用了。用户需要滚动、比对、再滚动。移动端的屏幕高度有限，长列表会显著提高跳出率。
解决办法不是删减内容，而是分层：首屏给出筛选标签与搜索框，把“缩小范围”这一步前置。
问题：nba直播jrs 的排序逻辑是什么
排序权重由三项构成：当日赛程权重占 50%，近七天讨论热度占 30%，编辑人工加权占 20%。人工加权主要用于修正算法无法识别的特殊情况，例如球星复出、纪录冲击、宿敌对决。
这套权重每周复核一次，调整记录会体现在更新日志里，避免排序黑箱化。
评分是怎么算出来的
评分由三名编辑独立打分后取均值，再保留一位小数。打分维度有三项：分差是否在 10 分以内、关键时刻回合数量、球星个人表现是否达到赛季均值以上。三项各占三分之一权重。
评分只反映“这场比赛的观赏性”，不代表球队实力，也不代表画质。页面在每张卡片的来源字段中标注了数据出处。
数据口径与更新节奏
赛程时间以官方赛程接口为准，人工比对后录入，误差容忍度为 5 分钟。评分与类型字段由编辑填写，来源字段标注具体出处。统计口径的说明在页脚固定展示，不随活动变动。
工作日的两次更新分别在 09:30 与 21:00，季后赛期间增加到四次。若遇临时改期，会在更新日志中单独注明。
移动端的取舍：加载速度优先
页面全部使用内联样式与原生脚本，零外部资源请求。图片统一为 WebP 并设置占位色块，避免加载过程中的布局抖动。首屏不放置大图轮播，把 LCP 控制在一秒出头。
代价是视觉表现相对克制，没有复杂的动效与渐变。但对一个以效率为先的导航页来说，这个取舍是值得的。
我们不做的事
不自动播放、不弹窗引导、不要求注册、不插入第三方统计脚本。评论板块只做展示，不提供提交入口，避免引入内容审核与脚本加载的双重负担。
这些“不做”看起来消极，实际上是让页面保持长期可维护的前提。
