<p>用 Date.now() 计算“几分钟前”需用 Math.floor((Date.now() - targetTime) / 60000) 获取完整分钟数，注意处理负值、零值及 DOM 节流更新，并确保服务端时间含时区。</p>
JavaScript 怎么用 Date.now() 计算“几分钟前”
直接拿当前时间戳减去目标时间戳，除以 60000（1 分钟 = 60 × 1000 毫秒），再取整就行。关键不是算不准，而是容易忽略时区和精度问题。
-
Date.now()返回的是本地时区的毫秒数，只要前后都用它，时区就自动对齐，不用手动转 UTC - 别用
new Date().getTime()替代 —— 虽然结果一样，但Date.now()更轻量、无对象创建开销 - 计算前务必确保目标时间是有效
Date对象；字符串如"2024-05-20T14:30:00"可直接传给new Date()，但"2024/05/20 14:30"在 Safari 下可能解析失败
为什么 Math.floor() 比 Math.round() 更合适
“3 分钟前”这种表述隐含向下取整逻辑：只要没满 4 分钟，就该显示“3 分钟前”，而不是四舍五入成“4”。否则刚过 3 分 29 秒就跳成“4 分钟前”，体验突兀。
- 用
Math.floor(diffMs / 60000)得到的是完整分钟数，符合自然语言习惯 - 如果 diffMs 是负数（未来时间），
Math.floor()会返回更小的负数（比如 -3.7 → -4），需提前判断并处理为“即将”或“还未发生” - 边界情况：刚好 0 分钟时，应显示“刚刚”而非“0 分钟前”，这个判断要写在 floor 之前
怎么避免 DOM 更新卡顿或重复计算
每秒都重算所有“X 分钟前”的节点？浏览器扛不住，尤其列表长的时候。得用节流 + 时间戳缓存。
- 不要给每个元素绑定
setInterval；改用单个定时器（比如每 30 秒触发一次），遍历所有带data-timestamp属性的元素批量更新 - 把原始时间戳存在
data-timestamp里（单位毫秒），而不是字符串或Date对象，避免反复 new Date() 解析开销 - 首次渲染时就计算一次并缓存结果，后续只在差值 ≥ 60000ms 时才重算，减少无效更新
兼容性差的写法：别用 Intl.RelativeTimeFormat 直接做“几分钟前”
虽然 Intl.RelativeTimeFormat 看起来高级，但它不支持“精确到分钟”的相对格式（比如没有 { unit: 'minute', value: 3 } 这种输出 “3 minutes ago” 的稳定行为），各浏览器对 numeric: "auto" 的实现也不一致，iOS Safari 甚至会把 1 分钟显示成 “in 1 minute” 而非 “1 minute ago”。
立即学习“前端免费学习笔记（深入）”；
- 真正稳定的方案还是手算分钟数，再拼字符串：
${minutes} 分钟前 -
Intl.RelativeTimeFormat更适合“昨天”“上周”“明年”这类粗粒度场景，不是本需求的解 - 如果必须国际化，按语言分别维护简单映射表比依赖 API 更可控
最易被忽略的一点：服务端返回的时间字段，一定要确认是 ISO 8601 格式且带时区（如 "2024-05-20T14:30:00+08:00"），否则前端用 new Date() 解析出来可能偏移一整天——这个坑没法靠 JS 代码补救，得从接口源头卡住。
