HTML不计算热度，仅负责展示；热度由后端或JavaScript基于浏览、点赞、评论及时间衰减等加权计算，再通过textContent安全注入DOM，CSS仅作视觉反馈，需注意时区一致性和XSS防护。
HTML 本身不实现热度算法，它只负责展示结果
热度计算是后端或 JavaScript 的事，HTML 没有运算能力，也不能读取用户行为数据。你看到的“热度值”一定是其他地方算好后，再塞进 <div> 或 <span> 里渲染出来的。
常见错误现象：document.getElementById("hot-score").innerText = "热度: 92" 这行代码看起来像在“计算”，其实只是硬编码或从接口取来的结果——真正的加权逻辑藏在别处。
- 浏览、点赞、评论数必须由服务端记录（比如存 MySQL / Redis），前端无法可信获取真实计数
- 时间衰减（比如 24 小时内权重更高）必须在服务端或 JS 中用
Date.now()计算，HTML 标签里写死data-weight="0.8"没意义 - 如果用纯静态 HTML 模拟热度，只能靠 JS 在加载时伪造，但刷新就重置，不反映真实状态
用 JavaScript 实现简易热度加权公式（含时间衰减）
典型场景：前端拿到原始数据 { views: 1200, likes: 86, comments: 23, createdAt: "2024-05-20T08:30:00Z" }，需要实时算出一个归一化热度分（0–100）。
为什么这样做：避免后端每次请求都计算，适合低频更新的内容页；但要注意，JS 算法不能替代服务端校验，尤其涉及排序或排行榜时。
立即学习“前端免费学习笔记（深入）”；
- 基础公式示例：
score = (views * 1 + likes * 5 + comments * 10) / Math.max(1, Math.pow(hoursSinceCreated, 0.5)) -
hoursSinceCreated要用new Date()和createdAt差值算，别直接用字符串比较 - 注意浮点精度：用
Math.round(score * 10) / 10控制小数位，避免显示87.33333333333333 - 别在循环里反复解析时间戳——先算一次
baseTime = new Date().getTime()，后面都用毫秒差
后端返回热度字段时，HTML 怎么安全接收和展示
最稳妥的做法是后端直接返回已加权的 hotScore 字段（如 JSON API 返回 {"hotScore": 89.4}），HTML 只做呈现。
容易踩的坑：把未过滤的数值直接插入 DOM，导致 XSS 或格式错乱。
- 用
textContent而非innerHTML设置热度值，防止hotScore被注入 HTML 标签 - 如果后端返回的是字符串（如
"89.4%"），前端别再拼接单位，否则可能变成"89.4%%" - 考虑降级：API 失败时，
<span class="hot-score">--</span>比留空或报错更友好 - 不要用
title属性塞原始数据（如title="views=1200,likes=86"），暴露过多业务细节且无语义
CSS 如何配合热度做视觉反馈，但不干扰算法
热度可视化是纯表现层任务，CSS 只管颜色、动画、尺寸变化，和加权逻辑完全解耦。
性能影响明显：用 transform 和 opacity 做动效，别用 width 或 height 触发重排。
- 定义类名按区间区分：
hot-score--low（0–30）、hot-score--mid（31–70）、hot-score--high（71–100） - 用 CSS 自定义属性传值：
<div class="hot-indicator" style="--score: 89.4"></div>，然后在 CSS 里用calc()控制宽度或透明度 - 避免用 JS 频繁改
style.color——统一用类名切换，更易维护也更快 - 别在
@keyframes里写热度阈值判断，动画逻辑和业务规则混在一起后期难调试
实际部署时，最常被忽略的是时间基准一致性：前端用本地时间算衰减，和服务端用 UTC 时间算的结果可能偏差几小时。尤其跨时区用户，这个差值会让“24 小时热榜”在部分地区提前下榜。
