必须存ISO 8601字符串而非毫秒数，因data属性值虽为字符串，但毫秒数无时区信息导致解析歧义、机器不可读，且需额外转换易出错；推荐存如"2024-05-22T14:30:18Z"格式。
直接存 ISO 8601 字符串，别存毫秒数时间戳。浏览器不认 1715269860123 这种数字，datetime 属性和 data- 属性都要求字符串格式，且必须带时区信息才可靠。
为什么不能把毫秒数直接塞进 data-timestamp
所有 data- 属性值都是字符串，但问题不在类型转换——而在于语义丢失和解析歧义：
-
data-timestamp="1715269860123"看似能用new Date(1715269860123)解析，但没人知道这到底是 UTC 还是东八区本地时间，结果可能偏移 8 小时 - 服务端渲染或静态 HTML 里硬编码这个数字，前端 JS 读出来仍是字符串，需额外
parseInt()再转Date，多一步就多一个出错点 - CSS 或其他工具（比如爬虫、无障碍阅读器）完全无法理解这个数字，失去机器可读性
data-last-active 应该存什么格式
存完整 ISO 8601 字符串，推荐 UTC 格式（以 Z 结尾）：
<div data-last-active="2024-05-22T14:30:18Z" data-status="active"></div>
- 后端生成时直接输出
toISOString()结果，避免 JS 在前端拼接年月日——漏补零、忽略夏令时、时区计算错误全躲开 - JS 侧读取后可直接传给
new Date()，无需任何中间处理：new Date(el.dataset.lastActive)安全有效 - 如果必须用本地时区（比如展示“用户本地最后上线时间”），则用
Intl.DateTimeFormat构造带偏移的 ISO 字符串，不要用toString()或toTimeString()—— 它们不是标准格式
读取时怎么避免类型陷阱
dataset 返回的全是字符串，哪怕你写的是 data-count="42"，读出来也是 "42"。时间戳同理：
立即学习“前端免费学习笔记（深入）”；
- 别写
if (el.dataset.lastActive > Date.now())—— 字符串比较毫无意义 - 正确做法是先转成
Date对象：const last = new Date(el.dataset.lastActive); if (last.getTime() > Date.now()) { ... } - 注意容错：万一后端没传或传了空值，
new Date("")会返回Invalid Date，建议加isNaN(last.getTime())判断 - 用
getAttribute()而不是dataset读取更稳妥，尤其在动态修改过属性之后 ——dataset有缓存行为，可能读不到最新值
真正容易被忽略的点是：data 属性不是状态容器，它只负责把初始时间戳“摆上 DOM”，后续状态变更（比如用户又活跃了一次）必须靠 JS 主动调用 setAttribute('data-last-active', newDate.toISOString()) 才会更新 HTML 源码；只改 dataset.lastActive 是假更新，刷新页面就丢。
