JavaScript Date对象存在时区、解析、方法命名等多重陷阱：字符串解析跨浏览器不一致，getMonth()返回0-11易致月份错位，时区处理需用toISOString()或toLocaleString()，日期计算应避免毫秒硬算而操作结构，且Date可变需克隆。

JavaScript 的 Date 对象不是“用起来就对”的类型——它默认本地时区、构造行为不一致、获取/设置方法命名反直觉，稍不注意就会在跨时区、月初月末、夏令时场景出错。

创建 Date 对象时，字符串解析最危险

传入字符串（如 "2025-03-15"）看似简单，但浏览器解析规则不统一：new Date("2025-03-15") 在 Chrome 中按 UTC 解析（变成 3 月 15 日 00:00:00 UTC），在 Safari 中却按本地时区解析。结果同一天在不同设备上可能差 8 小时。

• 安全做法：显式传入年、月、日数字参数，new Date(2025, 2, 15)（注意月份从 0 开始）
• 若必须用字符串，加时间部分并带时区标识，如 "2025-03-15T00:00:00Z"（Z 表示 UTC）或 "2025-03-15T00:00:00+0800"
• 避免 new Date("2025/03/15") —— 斜杠格式在 IE 中可能直接报 Invalid Date

getMonth() 和 getFullYear() 返回值差异大

getMonth() 返回 0–11，getDate() 返回 1–31，getFullYear() 才是完整年份。这个设计导致大量“月份总差一个月”的 bug。

const d = new Date(2025, 0, 1); // 2025年1月1日
console.log(d.getMonth());     // 0（不是 1）
console.log(d.getDate());      // 1（正确）
console.log(d.getFullYear());  // 2025（正确）

• 格式化输出时别直接拼接 date.getMonth() + 1，先判断是否为 0 再加 1
• 用 d.toLocaleDateString("zh-CN", { month: "2-digit" }) 更可靠，由系统处理本地化逻辑
• 需要计算下个月？别手动 setMonth(getMonth() + 1)，改用 new Date(d.getFullYear(), d.getMonth() + 1, 1) 避免溢出（比如 1 月 31 日加一个月会跳到 3 月 3 日）

时区处理靠 toISOString() 和 getTimezoneOffset()

Date 对象内部始终以毫秒数（UTC 时间戳）存储，但所有 get* 方法（如 getHours()）返回的是**本地时区**值；而 toISOString() 固定返回 UTC 格式字符串。

• 要存服务器时间？优先用 date.toISOString()（如 "2025-03-15T08:30:00.000Z"），后端统一按 UTC 解析
• 要显示用户本地时间？直接 date.toLocaleString() 即可，不用手动算偏移
• 想确认当前环境时区偏移？new Date().getTimezoneOffset() 返回分钟数（东八区为 -480），注意符号方向和单位

日期计算别用毫秒硬算，用现代 API 替代

手动加减 24 * 60 * 60 * 1000 毫秒来算“昨天”“下周”，会在夏令时切换日出错（比如某天只有 23 小时）。更稳妥的方式是操作日期结构本身。

• 加一天：用 new Date(date.getFullYear(), date.getMonth(), date.getDate() + 1)
• 比较两个日期是否同天：用 date1.toDateString() === date2.toDateString()
• 真正需要精确到毫秒的场景（如倒计时），才用 date.getTime() 计算差值
• 新项目建议引入 date-fns 或 dayjs，它们默认不可变、API 更语义化（如 addDays(date, 1)）

最常被忽略的一点：Date 对象是可变的。所有 set* 方法（如 setDate()）都会修改原对象，不是返回新实例。传参前记得 new Date(originalDate) 克隆一份，否则副作用会悄悄影响其他逻辑。