时间戳转换失败主因是单位混淆：10位为秒级需×1000，13位为毫秒级可直用；data属性取值须先转数字再判长度；字符串解析须用ISO 8601标准格式；推荐用Intl.DateTimeFormat安全格式化。
时间戳转换失败，八成是单位搞错了——10位是秒，13位是毫秒，混用直接变成 Invalid Date 或显示 1970 年。
怎么判断时间戳是秒还是毫秒
别猜，直接看长度：
- 10 位数字（如
1712420760）→ 是秒级时间戳，必须乘以1000再传给new Date() - 13 位数字（如
1712420760123）→ 是毫秒级，可直接用 - 从 HTML
data-属性读出来的，哪怕看着像数字，也一定是字符串，得先转Number()或parseInt()，否则new Date("1712420760")会尝试当 ISO 字符串解析，结果是Invalid Date
new Date() 解析字符串时的坑
浏览器对字符串格式极其敏感，尤其在 Safari 和旧版 WebView 中：
-
new Date("2025-04-06 13:26:00")→ ❌ 大概率失败（空格分隔不标准） -
new Date("2025/04/06")→ ❌ Safari 不认斜杠 -
new Date("2025-04-06T13:26:00Z")→ ✅ ISO 8601 标准格式，带Z表示 UTC，最稳 - 如果后端返回的是纯数字时间戳（推荐），就别走字符串解析这条路，直接
new Date(1712420760000)
用 Intl.DateTimeFormat 做安全格式化
不用拼接、不手动算时区偏移，靠浏览器原生 API 最省心：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 指定
timeZone用 IANA 名（如"Asia/Shanghai"），别用"CST"或"GMT+8"—— 它们不唯一，也不含夏令时逻辑 - 构造实例开销极小，动态切换时区时，直接
new Intl.DateTimeFormat(...)，别试图复用或缓存 formatter - SSR（服务端渲染）场景下，Node.js 可能不支持全部时区数据，只在客户端执行格式化更可靠
- 示例：
new Intl.DateTimeFormat("zh-CN", { timeZone: "America/New_York", hour12: false }).format(new Date(1716215400000))→"2024-05-20 02:30:00"
data 属性里存时间戳，怎么安全读取和使用
HTML 中写 <div data-timestamp="1712420760"></div> 很常见，但容易漏掉两步：
- 先用
el.getAttribute("data-timestamp")拿到的是字符串，必须转数字：Number(el.getAttribute("data-timestamp"))或parseInt(el.getAttribute("data-timestamp"), 10) - 再判断长度：10 位就
* 1000，13 位直接传入new Date() - 别在控制台只打
el.getAttribute("data-timestamp")就完事，要连带typeof和.trim()一起查，防空格、换行、不可见字符
真正难的不是写对一行代码，而是每次拿到时间数据都下意识问一句：这单位是秒还是毫秒？它是不是被当成字符串塞进去了？
