原生 Date 够用但易出错；Moment.js 已停更，新项目应避免。推荐 date-fns（轻量、不可变、tree-shakable）或 luxon（强时区支持），并统一团队时间语义认知。
原生 Date 对象够用，但写业务逻辑时容易出错；Moment.js 曾是事实标准，但已进入维护模式，不建议新项目引入。
为什么原生 Date 经常让人踩坑
它没有不可变性、解析行为不一致、时区处理模糊，且 API 设计反直觉。比如：
-
new Date('2023-10-01')在 Safari 和 Chrome 中可能解析为 UTC 或本地时区，取决于格式是否含时分秒 -
getMonth()返回 0–11，getDay()返回 0–6（星期几），不是日期数字 -
setFullYear(2023, 1, 30)设置 2 月 30 日会自动溢出到 3 月 2 日，但没人告诉你它悄悄改了 - 没有内置的格式化方法，
toLocaleString()输出受系统 locale 和选项影响大，难以稳定控制
用 Intl.DateTimeFormat 替代 Moment 格式化
现代浏览器支持良好（IE 除外），可精准控制语言、时区、粒度，且不引入第三方包。
const date = new Date('2023-05-15T14:30:00Z');
const formatter = new Intl.DateTimeFormat('zh-CN', {
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
second: '2-digit',
timeZone: 'Asia/Shanghai'
});
console.log(formatter.format(date)); // "2023-05-15 22:30:00"
- 时区必须显式传
timeZone，否则用用户本地时区 - 格式键（如
month: 'short'）不支持自定义模板，要拼字符串得靠formatToParts() - 若需 ISO 8601 字符串（含时区），直接用
date.toISOString()，但注意它永远输出 UTC
用 date-fns 替代 Moment 的计算与操作
Moment 是单个大对象 + 原型链修改，date-fns 是纯函数、不可变、tree-shakable，体积小得多。
立即学习“Java免费学习笔记（深入）”；
import { addDays, format, parseISO, isAfter } from 'date-fns';
const d = parseISO('2023-09-20');
const tomorrow = addDays(d, 1);
console.log(format(tomorrow, 'yyyy-MM-dd')); // "2023-09-21"
console.log(isAfter(tomorrow, d)); // true
- 所有函数第一个参数都是
Date实例，不接受字符串（除非用parseISO等专用解析函数） - 无全局状态，不用担心多处调用互相污染
- 不处理时区转换 —— 它把时区问题留给开发者明确决定：用
zonedTimeToUtc（来自date-fns-tz）或自己用toLocaleString+timeZone
新项目该选什么：date-fns 还是 luxon？
如果项目需要强时区支持（如跨地区日程调度）、又不想手写时区逻辑，luxon 更合适；否则 date-fns 足够轻量可靠。
-
luxon的DateTime对象自带时区信息，DateTime.fromISO('2023-01-01', { zone: 'Europe/London' })可稳定构造 -
date-fns默认所有操作都在本地时区，utcToZonedTime需额外依赖date-fns-tz，配置略繁琐 - 两者都不再需要 Moment 的
moment().add(1, 'day')这类魔数字符串，类型更安全
真正难的是统一团队对“时间语义”的理解：这个时间是用户本地时间？服务器时间？UTC 时间？存数据库用什么格式？前端展示要不要自动换算？库只是工具，没解决这个问题之前，换哪个库都还会出错。
