核心是后端提供带rank字段的标准REST接口，前端用SSE或指数退避轮询获取更新，局部DOM修改而非重绘，严格过滤用户名防XSS，禁用localStorage缓存榜单。
直接用 HTML + JavaScript 做实时积分排行榜，核心不是“怎么展示”，而是“怎么安全、稳定、低延迟地拿到并更新数据”——前端本身不存积分，所有排名必须来自后端接口，否则容易被篡改、无法排序、也不支持分页和实时刷新。
怎么设计排行榜数据接口（关键第一步）
别自己在前端算排名。浏览器里用 Array.sort() 排序看似简单，但用户数一过百，积分变动频繁时，你会遇到：排序不准（浮点误差）、无法处理并列名次（比如两人同分该是第1还是第2？）、没考虑分页导致卡顿、更没法做“只查前100名”的性能优化。
- 后端必须提供标准 REST 接口，例如
GET /api/rankings?limit=50&offset=0，返回带rank字段的数组（由数据库ROW_NUMBER() OVER (ORDER BY score DESC)或 RedisZREVRANGE生成） - 响应体至少包含：
uid、username、score、rank、updated_at - 务必要求接口支持 ETag 或
Last-Modified，方便前端用cache-control减少重复拉取
怎么用 JavaScript 实时刷新且不卡页面
“实时”不等于“每秒轮询”。高频轮询（如 setInterval(() => fetch(), 1000)）会快速打爆浏览器连接池，尤其在 Chrome 下默认对同一域名限制 6 个并发请求，还可能触发后端限流。
- 首次加载用
fetch()拿全量；后续更新优先走 Server-Sent Events（SSE），后端发data: {uid:123,score:9876}，前端用EventSource监听，只局部更新 DOM 节点 - 如果 SSE 不可用（比如某些 CDN 或老旧环境），改用指数退避轮询：
setTimeout(() => poll(), 1000 * Math.pow(1.5, retryCount))，最大间隔设到 30 秒 - 更新 DOM 时避免整表重绘：用
document.getElementById('rank-' + uid).querySelector('.score').textContent = newScore直接改字段，而不是innerHTML = ''后重新拼接整个列表
怎么防止 XSS 和恶意用户名破坏布局
排行榜里 username 是用户可控字段，直接 innerHTML = data.username 等于给 XSS 开门。更隐蔽的问题是：超长昵称（如 200 字符）、含零宽空格、RTL 字符、emoji 组合会导致表格错位、换行溢出甚至触发 Safari 渲染 bug。
立即学习“前端免费学习笔记（深入）”；
- 服务端返回前必须做基础过滤：移除控制字符、截断长度（建议 ≤ 16 字符）、转义 HTML 特殊符号（
<→） - 前端渲染时统一用
textContent而非innerHTML插入昵称；需要高亮搜索词时，用document.createTextNode()+span手动包裹 - CSS 层面加防护：
.username { overflow: hidden; text-overflow: ellipsis; white-space: nowrap; max-width: 120px; }，防撑破容器
为什么别用 localStorage 缓存排行榜数据
有人想“先显示缓存，再拉新数据”，结果发现：缓存里的积分永远比服务器旧，用户刷了 10 分，排行榜还显示昨天的数字，信任感直接崩塌。localStorage 还没法按用户维度隔离（A 用户看到 B 用户的缓存）。
- 缓存只用于降级场景：网络失败时展示“最后成功加载时间 + 提示‘暂未更新’”，而不是假装数据新鲜
- 真要提升体验，用 HTTP Cache（
Cache-Control: public, max-age=30）让浏览器自动管理，比手写 localStorage 可靠得多 - 如果必须本地排序（比如离线演示），确保数据源带
etag，每次 fetch 都带If-None-Match，服务端 304 响应即可省流量
最常被忽略的一点：排行榜的“实时”是有业务边界的。用户积分变化不等于立刻影响排名——比如后台批处理积分、风控审核延迟、分数四舍五入逻辑。前端强行追求毫秒级同步，反而会让用户困惑“为什么我+5分，排名没动”。跟产品确认好“可接受的延迟窗口”（通常是 5–30 秒），比堆技术方案重要得多。
