用 table 渲染更靠谱：语义正确、无障碍友好、兼容性好；需防 js 刷分，积分校验必须在服务端；移动端应精简字段，用 details 或 media query 隐藏次要信息。
用 table 还是 div 渲染排行榜更靠谱？
纯展示型积分榜，table 是更稳的选择。它天然语义正确、屏幕阅读器友好、默认支持列对齐和响应式（配合 display: block + 横向滚动），且在旧版浏览器里几乎零兼容问题。用 div 堆砌容易漏掉 role="row" 和 aria-colindex，导致残障用户无法理解排名逻辑。除非你要做带拖拽排序或实时动画的交互榜，否则别为了“看起来现代”硬上 Flex/Grid。
sort() 排序时数字被当字符串处理怎么办？
JavaScript 的 Array.prototype.sort() 默认按字符串字典序排，"10" 会排在 "2" 前面。必须显式传入比较函数：
users.sort((a, b) => b.points - a.points);
sort() 排序时数字被当字符串处理怎么办？
JavaScript 的 Array.prototype.sort() 默认按字符串字典序排，"10" 会排在 "2" 前面。必须显式传入比较函数：
users.sort((a, b) => b.points - a.points);
注意三点：
- 减法顺序决定升/降序（
b - a是降序） - 确保
a.points和b.points是数字类型，不是字符串"150"；可加Number(a.points)防错 - 如果数据来自 JSON 或表单，字段可能为
null或undefined，得先兜底：?? 0
前端直接渲染排行榜，用户改 JS 变量能刷分吗？
能，而且非常容易。只要积分数据存在前端 JS 对象里（比如 users = [{name: "Alice", points: 120}]），用户开控制台输 users[0].points = 99999 就生效了。这不是漏洞，是前端渲染的固有边界——所有展示逻辑都可被绕过。
真正要防刷分，必须：
- 积分计算和校验只在服务端做
- 前端只负责请求 /api/leaderboard 并渲染返回结果
- 即使加了「本地缓存」或「离线模式」，缓存的数据也应标记为「只读展示」，不参与任何业务判定
移动端小屏看不全「用户名+积分+等级+头像」怎么办？
别堆信息。优先保留「名次+用户名+积分」三要素，其他如等级图标、头像、签到天数等，在小屏上用折叠方式处理：
- 用 details/summary 标签实现点击展开（原生语义，无需 JS）
- 或 CSS 控制：给次要列加 class="mobile-hidden"，媒体查询里设 display: none
- 别用「左右滑动表格」，手指容易误触行点击，且焦点管理混乱
details/summary 标签实现点击展开（原生语义，无需 JS）
- 或 CSS 控制：给次要列加 class="mobile-hidden"，媒体查询里设 display: none
- 别用「左右滑动表格」，手指容易误触行点击，且焦点管理混乱
积分榜最麻烦的从来不是怎么画出来，而是数据来源是否可信、更新时机是否合理、以及用户一眼能否看清自己在哪一档——这些没法靠一个 table 标签解决。
