JavaScript Date对象存在时区、解析、方法命名等多重陷阱：字符串解析跨浏览器不一致，getMonth()返回0-11易致月份错位，时区处理需用toISOString()或toLocaleString()，日期计算应避免毫秒硬算而操作结构，且Date可变需克隆。
JavaScript 的 Date 对象不是“用起来就对”的类型——它默认本地时区、构造行为不一致、获取/设置方法命名反直觉，稍不注意就会在跨时区、月初月末、夏令时场景出错。
创建 Date 对象时，字符串解析最危险
传入字符串（如 "2024-03-15"）看似简单，但浏览器解析规则不统一：new Date("2024-03-15") 在 Chrome 中按 UTC 解析（变成 3 月 15 日 00:00:00 UTC），在 Safari 中却按本地时区解析。结果同一天在不同设备上可能差 8 小时。
- 安全做法：显式传入年、月、日数字参数，
new Date(2024, 2, 15)（注意月份从 0 开始） - 若必须用字符串，加时间部分并带时区标识，如
"2024-03-15T00:00:00Z"（Z 表示 UTC）或"2024-03-15T00:00:00+0800" - 避免
new Date("2024/03/15")—— 斜杠格式在 IE 中可能直接报Invalid Date
getMonth() 和 getFullYear() 返回值差异大
getMonth() 返回 0–11，getDate() 返回 1–31，getFullYear() 才是完整年份。这个设计导致大量“月份总差一个月”的 bug。
const d = new Date(2024, 0, 1); // 2024年1月1日 console.log(d.getMonth()); // 0（不是 1） console.log(d.getDate()); // 1（正确） console.log(d.getFullYear()); // 2024（正确）
- 格式化输出时别直接拼接
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 格式字符串。
立即学习“Java免费学习笔记（深入）”；
- 要存服务器时间？优先用
date.toISOString()（如"2024-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) 克隆一份，否则副作用会悄悄影响其他逻辑。
