用 setInterval 每30秒更新一次，首次渲染立即执行，统一处理时间戳单位（秒×1000转毫秒），避免时区错误，组件卸载时清除定时器，SSR 仅静态渲染，hydration 后启动定时器。
怎么用 JavaScript 实现“X分钟前”动态更新
直接改 DOM 文本不难，难在它得自动动、不卡顿、不越界。核心是用 setInterval 定期重算，但别设成 1 秒——人眼根本看不出区别，还白耗 CPU。
常见错误是每次都重新解析时间戳，或把 new Date() 写死在闭包外；还有人用 setTimeout 递归，结果跑着跑着就堆栈溢出。
- 用
Math.floor((now - timestamp) / 60000)算分钟数，别用Date.getMinutes()——那只是当前时间的分钟，不是差值 - 每 30 秒更新一次足够：人对“X分钟前”的感知本来就有模糊带，30 秒内误差完全可接受
- 首次渲染必须立刻执行，不能等第一次定时器触发，否则页面出来就是静态数字
- 记得清理定时器：组件卸载、元素移除时调
clearInterval，否则内存泄漏
为什么 new Date().toLocaleTimeString() 不适合做“X分钟前”
它只返回当前时间点的格式化字符串，比如 "14:22:05"，和“多久以前”毫无关系。有人误以为加个 relativeTime 选项就能行，但那是 Intl.RelativeTimeFormat 的事，而且它不自动刷新。
更隐蔽的坑是时区：如果后端给的是 UTC 时间戳，而前端直接扔给 new Date(timestamp)，浏览器会按本地时区解释——看起来差 8 小时，算出来的“X分钟前”就全错。
立即学习“前端免费学习笔记（深入）”；
使用 PptxGenJS 和 Python 解析，将结构化的 HTML/CSS 幻灯片内容转换为原生、可编辑的 PowerPoint（.pptx）演示文稿。
-
new Date(timestamp)默认按本地时区解析，要确保 timestamp 是毫秒级且已按 UTC 对齐 - 推荐统一用
new Date(timestamp * 1000)（如果后端给的是秒级）或直接传毫秒，避免歧义 -
Intl.RelativeTimeFormat可以生成“2 minutes ago”，但它不维护状态，也不自动更新，纯静态输出
Vue/React 里怎么避免重复创建定时器
函数组件里写 useEffect 或 mounted 钩子时，最容易漏掉依赖数组或清理逻辑，导致一个元素挂了多个定时器，数字狂跳。
错误示例：useEffect(() => { const t = setInterval(...); }, []) —— 看似只执行一次，但组件重渲染后，旧定时器没清，新定时器又起，越积越多。
- React 中必须在
useEffect返回函数里调clearInterval(t) - Vue 3 的
onMounted+onBeforeUnmount要配对使用，别只挂不卸 - 如果页面有多个“X分钟前”元素，别共用一个全局定时器——它们的时间戳不同，更新节奏也该独立
- 考虑封装成自定义 Hook 或 Composable，把定时器生命周期和时间计算逻辑收拢
服务端渲染（SSR）下怎么让“X分钟前”不出错
Node.js 环境没有 document 和 setInterval，直接跑前端逻辑会报错；更麻烦的是，SSR 渲染时时间是快照，用户看到的初始值可能已经过时几秒。
典型现象：首屏显示“0分钟前”，但实际请求是 30 秒前发的，用户一打开就发现数字立刻跳成“1分钟前”，体验割裂。
- SSR 阶段只渲染静态文本，比如
<span data-timestamp="1717023456000">刚刚</span>，不执行 JS 计算 - 客户端 Hydration 后再启动定时器，用
data-timestamp拿原始时间戳 - 避免在 SSR 里调
new Date()做服务端时间差计算——它和用户本地时间不同步，算出来毫无意义 - 如果必须服务端预估，只用于兜底（如 >24 小时就显示具体日期），别碰分钟级精度
事情说清了就结束。最常被忽略的其实是时间戳单位——后端传来的是秒还是毫秒，一眼扫过去容易看岔，一错就差一千倍。
