原生 Date 够用但易踩坑:ISO 字符串如 '2025-10-05' 被强制按 UTC 解析致时区错乱;加天可用 setDate,加月需第三方库;格式化推荐 Intl.DateTimeFormat 配 'sv-SE'。
JavaScript 原生 Date 对象够用,但容易踩坑——比如时区错乱、月份从 0 开始、字符串解析不可靠。别急着封装工具函数,先搞清哪些场景必须用第三方库(如 date-fns 或 dayjs),哪些直接用原生就能稳。
这是 ISO 8601 字符串解析的时区陷阱:Date 遇到带短横线的格式(如 '2025-10-05')会**强制按 UTC 解析**,再转成本地时区显示。结果在东八区看到的是 UTC 时间减 8 小时后的日期。
new Date(2025, 9, 5)(注意月份是 0 起始)new Date('2025-10-05T00:00:00')
new Date('2025/10/05') 在 Safari 里可能失败,new Date('2025-10-05') 时区不一致直接改 date.setDate(date.getDate() + 7) 可以加天,但加月份不能简单 setMonth(getMonth() + 1) —— 会跳过 31 日不存在的月份(比如 1 月 31 日加一个月变成 3 月 3 日)。
setDate() 是安全的,JS 自动进位/借位setMonth(m + 1) 在月末日期上行为不一致date-fns 的 addMonths(date, 1) 或 dayjs 的 .add(1, 'month')
别手写拼接,也别依赖 的区域设置(它可能输出中文星期、AM/PM 等不可控内容)。优先用 
Intl.DateTimeFormat,它是标准、可配置、无需额外包。
立即学习“Java免费学习笔记(深入)”;
const fmt = new Intl.DateTimeFormat('sv-SE', {
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
hour12: false
});
fmt.format(new Date()); // → '2025-10-05 14:30'
'sv-SE' 是关键:它固定输出 ISO 格式数字,且不含时区偏移year, month 等)必须显式声明,否则可能缺字段toISOString() 返回 UTC 时间,不是本地时间toJSON() 和 toString() 输出含时区或不可预测格式真正麻烦的从来不是“怎么显示”,而是“怎么存、怎么传、怎么比”。后端要的是 UTC 时间戳还是 ISO 字符串?用户选的是本地时间还是某个固定时区?这些决策点比格式化代码本身影响更大。