时间戳格式化失败八成因单位错误：10位为秒级（需×1000），13位为毫秒级；字符串须转数字并trim，优先用iso格式（如"2025-04-06t13:26:00z"）和intl.datetimeformat安全格式化。
时间戳格式化失败，八成是单位搞错了——10位是秒，13位是毫秒，混用直接变成 Invalid Date 或显示 1970 年。
怎么判断时间戳是秒还是毫秒
别猜，直接看长度：
-
10位数字（如1712420760）→ 秒级，必须乘以1000再传给new Date() -
13位数字（如1712420760123）→ 毫秒级，可直接用 - 从
data-属性读出来的值永远是字符串，哪怕看着像数字，也得先转：Number(el.getAttribute("data-timestamp"))或parseInt(el.getAttribute("data-timestamp"), 10) - 别忘了
.trim()：空格、换行、不可见字符会让parseInt返回NaN
new Date() 解析字符串时的坑
浏览器对字符串格式极其敏感，尤其在 Safari 和旧版 WebView 中：
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
-
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 最省心：
- 指定
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"
HTML 中 data-timestamp 怎么安全读取和使用
常见写法 <div data-timestamp="1712420760"></div>，但容易漏掉两步：
- 先用
el.getAttribute("data-timestamp")拿到的是字符串，必须转数字：Number(...)或parseInt(..., 10) - 再判断长度：
10位就* 1000，13位直接传入new Date() - 真正难的不是写对一行代码，而是每次拿到时间数据都下意识问一句：这单位是秒还是毫秒？
时区、单位、类型转换——这三个点只要漏一个，new Date() 就可能静默失败或错一天。别依赖控制台里一眼看上去“像数字”的值，typeof 和 .length 才是真相。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
