HTML不处理时间戳转换，实际由JavaScript操作DOM；需区分10位（秒级×1000）和13位（毫秒级）时间戳，字符串须转数字，避免toLocaleString()格式不一致，data-timestamp应用getAttribute读取并校验有效性。
HTML 本身不处理时间戳或日期转换，它只是容器；真正起作用的是 JavaScript —— 所有「HTML 中的时间戳转日期」行为，本质都是 JS 在操作 DOM 节点里的文本或属性值。
为什么 new Date(timestamp) 有时显示 NaN 或错误时间
常见错误现象：传入字符串 "1744480740" 却没转成数字，或传了 10 位时间戳却当成毫秒用（new Date(1744480740) 直接解析为 1970 年）。
- 10 位时间戳（秒级）必须乘
1000才能被new Date()正确识别为毫秒：new Date(1744480740 * 1000) - 13 位时间戳（毫秒级）可直接使用：
new Date(1744480740123) - 字符串形式必须先转数字：
new Date(Number("1744480740") * 1000)，否则new Date("1744480740")会尝试解析为日期字符串（失败则返回Invalid Date） - ISO 格式字符串（如
"2026-04-12T21:39:00Z"）可直接传入，无需转换
toLocaleString() 在不同浏览器里输出不一致怎么办
这个方法依赖系统区域设置，比如 en-US 下是 "4/12/2026, 9:39:00 PM"，而 zh-CN 下可能是 "2026年4月12日 下午9:39:00"，无法保证格式统一。
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 生产环境避免直接用
toLocaleString()做展示，除非你明确控制了locale和options参数 - 更可靠的方式是手动拼接：
date.getFullYear() + "-" + String(date.getMonth()+1).padStart(2,"0") + ... - 或者用轻量工具函数（不引入 moment 等大库）：
date.toISOString().slice(0,19).replace("T"," ")→ 得到"2026-04-12 21:39:00"（注意这是 UTC 时间） - 若需本地时区的 ISO 风格字符串，可用
date.toLocaleString("sv-SE", {hour12:false})（瑞典格式稳定，无 AM/PM）
HTML 中的 data-timestamp 属性怎么安全读取并渲染
很多前端框架或服务端模板会在 HTML 元素上写 data-timestamp="1744480740"，但直接 innerText 替换容易忽略类型和时区。
立即学习“前端免费学习笔记（深入）”；
- 务必用
getAttribute()读取，不要用dataset.timestamp—— 后者会自动转成小写且丢失前导零（虽然时间戳一般没前导零，但习惯要养） - 判断是否为有效数字：
const ts = Number(el.getAttribute("data-timestamp"));，再检查!isNaN(ts) && ts > 0 - 区分秒级/毫秒级：如果数值在 10 位（
1e9 ~ 2e9），大概率是秒级，应 ×1000；13 位（1e12 ~ 2e12）则直接用 - 渲染时建议加一层容错：
el.textContent = isValidDate(d) ? formatDate(d) : "Invalid date";
最易被忽略的一点：时间戳本身不含时区信息，但 new Date() 构造出的对象默认按本地时区解释 —— 如果原始时间戳来自 UTC（比如后端返回的 Unix 时间），而你想保持 UTC 显示，就得用 getUTCFullYear() 等方法，而不是 getFullYear()。这点在跨时区产品中几乎必踩。
