HTML本身不能实现在线用户列表，必须配合后端接口获取实时状态；前端用fetch或WebSocket请求数据并渲染，后端需基于session、心跳或Redis判断真实在线状态。
HTML本身不能实现在线用户列表，必须配合后端
纯HTML只是静态页面，无法获取实时用户状态。所谓“后台在线用户列表”，本质是前端展示 + 后端数据接口的组合。如果你只写了一个index.html文件就期望看到谁在线，那肯定看不到——浏览器不会自己去查数据库或 WebSocket 连接。
常见错误现象：页面空白、显示“undefined”、控制台报404或500、列表始终为空。
- 前端只需负责发起请求（如
fetch）并渲染JSON返回的用户数组 - 后端必须提供真实在线状态判断逻辑（比如基于
session、JWT token有效期、WebSocket心跳或Redis在线标记） - 若用
Node.js+Express，接口可能长这样：GET /api/users/online - 若用
Python Flask，需主动维护user_id → last_active_time映射，再过滤出5分钟内有活动的用户
前端用 fetch 渲染在线用户列表最简可行方案
假设后端已提供/api/users/online接口，返回格式为[{"id":1,"name":"张三","last_seen":"2024-06-12T10:22:30Z"}]，前端只需：
async function loadOnlineUsers() {
try {
const res = await fetch('/api/users/online');
const users = await res.json();
const list = document.getElementById('user-list');
list.innerHTML = users.map(u =>
`
` ).join(''); } catch (e) { console.error('加载失败:', e.message); } } loadOnlineUsers(); setInterval(loadOnlineUsers, 30000); // 每30秒刷新一次
注意：setInterval不是实时方案，仅适合低频更新场景；高并发或强实时性需求必须换WebSocket或Server-Sent Events。
- 别直接把
users数组console.log完就以为成功了，一定要检查list.innerHTML是否被正确赋值 - 如果后端返回字段名是
username而非name，模板里写u.username，否则渲染为空 - 时间字段若为
unix timestamp（如1718187750），需用new Date(u.last_seen * 1000)
为什么用 WebSocket 而不是轮询？关键区别在哪
当用户数超过几百、且要求“秒级可见掉线”，setInterval + fetch会迅速暴露问题：服务器压力大、延迟高、状态不同步。此时必须切到WebSocket。
典型错误认知：WebSocket只是“更酷的 AJAX”。其实它改变了通信模型——连接建立后，服务端可主动推送，不再依赖客户端问“还在吗？”
- 前端初始化：
const ws = new WebSocket('wss://your-api.com/ws') - 服务端需监听
connection和close事件，实时增删onlineUsers集合 - 每次有新连接或断开，立即广播更新后的用户列表给所有客户端
- 前端收到消息后调用
renderUserList(data.users)，无需自己定时拉取 - 兼容性注意：
WebSocket不支持 HTTP 页面直连ws://（需https://或本地http://localhost）
容易被忽略的三个后端细节
前端写得再漂亮，后端漏掉这些点，列表永远不准：
-
session过期时间要与“在线判定阈值”对齐。例如设maxAge: 30 * 60 * 1000（30分钟），但接口却查last_seen > now - 5min，结果就是用户关掉标签页20分钟后仍显示在线 - 没处理
浏览器崩溃/断网/强制杀进程等异常断连场景。仅靠onclose不够，需结合ping/pong心跳和超时踢出机制 - 多实例部署时，若用内存存在线用户，
Node.js cluster或多个Flask进程会导致状态不一致，必须改用Redis SETEX或PostgreSQL advisory lock做共享状态
真正的难点从来不在怎么画，而在于“谁算在线”这个定义能否在分布式、异常网络、各种客户端行为下保持一致。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
