JavaScript Date 对象存在时区解析差异、月份索引从0开始、set方法柔性溢出等隐含规则，需显式处理时区和边界校验以避免逻辑错误。
JavaScript 的 Date 对象不是“拿来就能用”的日期工具，它默认按本地时区解析字符串、getMonth() 从 0 开始、setFullYear() 和 setDate() 行为不一致——这些细节不处理好，时间逻辑就容易出错。
为什么 new Date('2023-10-05') 在某些浏览器里变成 10 月 4 日？
因为 ISO 格式字符串（如 '2023-10-05'）被规范定义为 UTC 时间，但部分旧版浏览器（尤其是 Safari 低版本）会错误地当作本地时间解析。更稳妥的做法是显式指定时区或拆解参数：
- 用
new Date(2023, 9, 5)（注意：月份是 0~11） - 或强制转为本地时间：
new Date('2023-10-05T00:00:00')（加T00:00:00） - 避免直接传
'2023/10/05'，它在 IE 中可能报Invalid Date
getMonth() 返回 0~11，但 setMonth(12) 会发生什么？
getMonth() 返回 0 表示一月，这是历史遗留设计；而 setMonth(12) 不会报错，而是自动进位：2023 年 12 月 → 变成 2024 年 1 月。类似地，setDate(32) 会让日期滚到下个月第 1 天。这种“柔性溢出”是 Date 的特性，不是 bug，但容易误判边界。
- 校验月份是否合法？别只看
date.getMonth() === 11，要结合getFullYear() - 需要严格限制范围时，先
setMonth()再getDate()检查是否被修正过 -
setFullYear(2023, 12, 1)等价于setFullYear(2024, 0, 1)
toISOString() 和 toLocaleDateString() 的时区陷阱
toISOString() 总返回 UTC 时间字符串（如 '2023-10-05T00:00:00.000Z'），而 toLocaleDateString() 完全依赖运行环境的系统时区和语言设置，同一段代码在东京和纽约显示完全不同。
立即学习“Java免费学习笔记（深入）”；
- 想固定输出中文格式的本地日期？用
toLocaleDateString('zh-CN', {year: 'numeric', month: '2-digit', day: '2-digit'}) - 服务端需要 UTC 时间？优先用
toISOString()，别用toString()或toUTCString()（后者含时区缩写，解析不稳定） -
new Date().getTimezoneOffset()返回的是 *分钟数*，且符号与 UTC 偏移相反（东八区返回-480）
真正难的不是记住所有方法名，而是理解每个方法背后隐含的时区上下文和溢出规则。比如 setHours(25) 是加一天还是报错？答案是：它会正常执行并让日期前进一天——这种“静默修正”恰恰是最容易漏掉的逻辑分支。
