真正可用的动态贡献值排行榜需html提供结构、js负责数据获取/排序/渲染，用语义化展示，按score降序排列，避免字符串比较陷阱，积分变更由后端驱动，前端仅展示并支持局部更新。
怎么用 HTML + 简单 JS 实现动态贡献值排行榜
纯 HTML 无法计算、排序或实时更新积分，必须配合 JavaScript。常见误区是以为用 <table> 列出来就叫“排行榜”，结果数据一变就得手动改 HTML —— 这不是排行榜，是快照。<p>真正能用的最小可行方案：HTML 提供容器结构，JS 负责拉取数据（本地数组或 fetch API）、按 <code>score 字段降序排序、生成 <li> 或 <tr> 插入 DOM。<ul>
<li>优先用 <code><ol></ol>（有序列表）包裹排名项，语义正确，且自带序号，不用手写 1. 2.
const contributors = [{name: "张三", score: 127}, {name: "李四", score: 98}]
a.score > b.score 默认字符串比（"100" 会返回 true），要写成 <code>a.score - b.score 或 Number(a.score) > Number(b.score)
发帖/帮助/审核行为如何对应到积分变动
积分规则不是 HTML 决定的，而是业务逻辑。HTML 只负责展示最终数值，但你要提前想清楚：哪些动作触发加减分？谁来执行加减？
典型场景下，前端只做「展示反馈」，不直接改分。比如用户点击「采纳回答」，应调用后端接口 /api/v1/answer/123/accept，由服务端校验权限、更新数据库、返回新积分，前端再刷新排行榜。
- 不要在前端用
localStorage自增积分，绕过服务端 → 容易被篡改、不同设备不一致、审核记录丢失 - 每类行为建议单独定义积分常量，比如：
const POINTS = {post: 5, answer: 10, review: 3}，方便后期调整 - 审核类操作（如通过一条帖子）往往需要双重确认，HTML 中对应按钮应禁用状态 + 加载动画，防止重复提交
为什么排行榜总显示旧数据？常见缓存和更新陷阱
最常踩的坑：页面加载一次数据后就再也不更新，或者用定时器无差别重拉全部榜单，导致性能差、用户看到延迟积分。
真实协作场景中，积分变动是稀疏、低频、点对点的。与其轮询全量榜单，不如让后端在关键操作后推送变更（如 WebSocket 发送 {type: "score_update", user_id: 456, delta: +10}），前端局部更新 DOM。
- 如果不用实时通信，至少加个「刷新」按钮，绑定
location.reload()或重新执行fetchRanking()，别让用户等 30 秒自动刷 - 浏览器缓存可能拦截
fetch('/api/ranking')，加个时间戳参数：fetch('/api/ranking?t=' + Date.now()) - 移动端 WebView（如微信内嵌页）对
fetch缓存更激进，建议服务端响应头加Cache-Control: no-cache
兼容性与无障碍要注意什么
排行榜不是炫技区，得让屏幕阅读器知道这是按分数排的列表，也得让老浏览器用户看清名次。
<ol></ol> 天然支持语义化序号，但若用 <div> + CSS counter 模拟序号，NVDA/JAWS 就读不出第几名 —— 直接用原生 <code><ol></ol>，别省这点事。
- 给每行加
role="row"和aria-label="张三，积分 127，排名第 1"，辅助技术用户能听清完整信息 - 别用颜色唯一标识高低分（如红=高，蓝=低），色盲用户无法分辨；加图标或文字前缀，比如
<span aria-hidden="true">?</span> 热门贡献者 - IE11 不支持
Array.prototype.sort()对对象数组稳定排序，若还须兼容，用localeCompare或引入 polyfill
积分逻辑越往后越复杂：权重系数、时效衰减、团队归属、冻结状态……HTML 层永远只是最后一层皮，别让它承担不该背的锅。
