JavaScript Date 对象本身不混乱，混乱的是直接用它做加减、跨时区、格式化或比较——因其 API 隐含大量陷阱：getMonth() 从 0 开始、setFullYear() 静默溢出、ISO 字符串解析在 Safari 等浏览器中被误当本地时间（规范定义为 UTC），且跨月/跨天计算易受夏令时和日历溢出影响。
JavaScript 的 Date 对象本身不混乱，混乱的是直接用它做加减、跨时区、格式化或比较——因为它的 API 设计隐含大量陷阱：getMonth() 从 0 开始、setFullYear() 会静默溢出、new Date('2023-01-01') 在 Safari 中可能解析为 UTC 而非本地时间。
为什么 new Date('2023-01-01') 在不同浏览器结果不一致
ISO 格式字符串（如 '2023-01-01'）被规范定义为 UTC 时间；但部分旧版浏览器（尤其是 Safari ≤ 15.4）将其错误地当作本地时间解析。这不是 bug，是历史兼容性行为差异。
- 安全写法永远显式指定时区：
new Date('2023-01-01T00:00:00')（无时区 = 本地）或new Date('2023-01-01T00:00:00Z')（明确 UTC） - 避免仅传字符串：用参数构造更可控，例如
new Date(2023, 0, 1)→ 注意0是一月 - 若必须解析用户输入的日期字符串，优先用
Intl.DateTimeFormat或第三方库（如date-fns的parseISO）
getMonth() 返回 0–11 而不是 1–12 的真实影响
这个设计导致几乎所有涉及月份的计算都容易出错，比如「获取下个月第一天」时直接 date.setMonth(date.getMonth() + 1) 看似合理，但若当前是 1 月 31 日，结果可能是 3 月 3 日（因 2 月没有 31 日，自动进位）。
- 月份加减务必配合
getDate()校验：先设为当月 1 日，再加减月份，避免溢出干扰 - 推荐用函数封装：
function addMonths(date, months) { const d = new Date(date); const day = d.getDate(); d.setMonth(d.getMonth() + months, 1); // 先置为当月1日 d.setDate(Math.min(day, new Date(d.getFullYear(), d.getMonth() + 1, 0).getDate())); return d; } - 不要依赖
toDateString()或toString()做展示——它们返回本地时区且格式不可控
跨天数计算别用毫秒除法：用 date-fns 的 differenceInDays 更可靠
手动算 (date2 - date1) / (1000 * 60 * 60 * 24) 看似直观，但会因夏令时切换（如某天只有 23 小时）导致结果偏差 ±1 天。
立即学习“Java免费学习笔记（深入）”；
-
date-fns/differenceInDays内部按日历日期差计算，无视时长波动 - 如果不能引入依赖，可用原生逻辑模拟：
function diffDays(d1, d2) { const a = new Date(d1); const b = new Date(d2); a.setHours(0,0,0,0); b.setHours(0,0,0,0); return Math.round((b - a) / 86400000); } - 注意：
Math.round是必须的，因为毫秒差除以 86400000 可能有浮点误差
真正难的不是写对一行 Date 代码，而是所有时间操作都得同步考虑时区、DST、日历溢出和字符串解析歧义——哪怕只做一个「显示距离现在还有几天」的功能，也得先决定：这个「天」是按用户本地日历算，还是按服务器 UTC 时间算？这点一旦定错，后续所有计算都会漂移。
