HTML通知时间分组教程：今天昨天分类大全

本文深入解析了如何在前端用 JavaScript 稳健实现通知时间的「今天 / 昨天 / 更早」语义化分组，直击开发者常踩的时区混乱、时间戳单位错误、浏览器解析差异、渲染标题重复等致命坑点；强调必须统一使用毫秒级时间戳进行计算（而非字符串或 Date 对象直接比较），通过 `Math.floor((Date.now() - notifyTime) / 86400000)` 精确获取整数天差，并严格按 0/1/≥2 分桶，同时规范后端时间格式（ISO 8601 或毫秒戳）、缓存当前时间、结构化分组后再顺序渲染——这套经过实战验证的方法，能让你的通知列表在任何时区、任何浏览器、任何夏令时切换下都准确可靠，彻底告别“昨天变今天、标题刷屏、Safari 和 Chrome 表现不一”的线上故障。

怎么用 JavaScript 对通知时间做「今天 / 昨天 / 更早」分组

直接结论：不能只靠 innerHTML 拼接，得先解析时间戳、计算相对天数、再按逻辑分桶。浏览器原生不提供「语义化日期分组」API，必须自己算。

常见错误是拿 new Date().toDateString() 和通知时间的 toDateString() 硬比——看似能区分今天昨天，但跨时区、夏令时、服务器时间与本地时间不一致时全崩。

• 务必统一用时间戳（毫秒）做减法，再除以 24 * 60 * 60 * 1000 得整数天差
• 用 Math.floor((now - notifyTime) / (24 * 60 * 60 * 1000)) 算「过去多少整天」，比 getDate() 稳定得多
• 分组键建议用字符串字面量："today"、"yesterday"、"older"，别用中文键名，避免模板渲染出错

后端返回的时间字段格式影响分组逻辑

如果后端给的是 ISO 字符串（如 "2024-05-20T09:30:00Z"），直接传给 new Date() 没问题；但如果给的是 Unix 秒级时间戳（如 1716207000），必须乘 1000 再构造 Date 对象，否则时间会错 1000 倍。

更隐蔽的坑是后端返回带时区偏移但没标注（如 "2024-05-20 09:30:00"），这种字符串在 Safari 上可能被当成本地时间解析，在 Chrome 可能被当成 UTC——结果同一条通知，在不同浏览器里分到不同组。

• 强制要求后端返回 ISO 8601 格式（含 Z 或 +08:00），或明确约定用毫秒时间戳
• 前端拿到时间字段后，立刻转成时间戳存为 notifyTimestamp，后续所有计算只用这个数字
• 避免在分组逻辑里反复调用 new Date()，把当前时间戳缓存为常量 const now = Date.now()

渲染时怎么让「今天 / 昨天」标题只出现一次

分组本身只是把通知数组变成对象：{ today: [...], yesterday: [...], older: [...] }，但 DOM 渲染时容易重复插入标题——比如用 forEach 遍历每个通知，遇到第一个「今天」就插个

今天

正确做法是先生成结构化数据，再按分组键顺序遍历渲染：

const groups = { today: [], yesterday: [], older: [] };
notifications.forEach(n => {
  const diffDays = Math.floor((now - n.timestamp) / 86400000);
  if (diffDays === 0) groups.today.push(n);
  else if (diffDays === 1) groups.yesterday.push(n);
  else groups.older.push(n);
});
<p>// 渲染时只遍历 keys，每个 key 插一次标题
Object.entries(groups).forEach(([key, list]) => {
if (list.length === 0) return;
html += <code><h4>${key === 'today' ? '今天' : key === 'yesterday' ? '昨天' : '更早'}</h4></code>;
list.forEach(n => html += <code><div class="notification">${n.content}</div></code>);
});</p>

时区和夏令时导致「昨天」变「今天」怎么办

本质是用户本地时间与服务器时间存在偏移，而你的分组逻辑依赖本地 Date.now()。例如服务器时间是 5 月 20 日 00:30，用户在西八区（UTC-8），本地时间还是 5 月 19 日 16:30——此时算出来 diffDays 是 0，归入「今天」，但用户直觉上这是「昨天」的消息。

解决思路不是改算法，而是明确产品定义：分组依据是「用户看到的时间」，那就必须用本地时间；如果业务强依赖服务器时间（如客服系统），就得让后端返回一个「服务端当天零点的时间戳」，前端用它代替 Date.now() 做基准。

• 大多数 C 端应用用本地时间即可，但需在文档里写明「按您手机系统时间分组」
• 绝对不要在分组逻辑里用 toLocaleDateString() 做比较，它受用户系统语言、时区、日历类型（如农历）影响，不可控
• 测试时手动改手机时区，验证「23:59 发的通知」在跨天后是否还显示「今天」——这是最常漏测的边界场景

分组逻辑看着简单，真正上线后出问题的，九成卡在时间戳单位、时区隐式转换、或者渲染时没去重标题。把时间全转成毫秒数字，中间别掺任何字符串操作，基本就稳了。

文中关于的知识介绍，希望对你的学习有所帮助！若是受益匪浅，那就动动鼠标收藏这篇《HTML通知时间分组教程：今天昨天分类大全》文章吧，也可关注golang学习网公众号了解相关技术文章。