JavaScript Date对象易在时区、字符串解析、月份索引（0起始）处出错；ISO字符串如'2023-10-01'被解析为UTC再转本地，导致跨浏览器差异；安全做法是显式指定时区或用数值构造，避免模糊字符串解析。
JavaScript 的 Date 对象不是“不好用”，而是容易在时区、字符串解析、月份索引这些地方掉坑里。直接上手写 new Date() 很快，但一到格式化、加减天数、跨时区比较，就容易出错。
为什么 new Date('2023-10-01') 在某些浏览器里变成 9 月 30 日？
因为 ISO 格式字符串（如 '2023-10-01'）被解析为 UTC 时间，再转成本地时区显示。比如你在东八区，new Date('2023-10-01') 实际创建的是 UTC 时间的 2023-10-01T00:00:00Z，对应本地就是 10 月 1 日上午 8 点 —— 这没问题；但如果你传的是 '2023-10-01 12:00'（带空格无时区），不同浏览器解析规则不一致，Safari 可能当本地时间，Chrome 当 UTC。
- 安全做法：显式指定时区，例如
'2023-10-01T00:00:00+08:00'或用new Date(2023, 9, 1)（注意：月份是 0 起始） - 避免用字符串构造器解析用户输入或后端返回的日期字符串，优先用
Date.parse()+ 手动校验，或直接拆解年月日 - 如果必须解析不确定格式的字符串，用
date-fns或dayjs这类库，它们对模糊输入更鲁棒
getMonth() 返回 0～11，但 getFullYear() 返回四位数——怎么统一处理？
这是 Date 原生 API 的固定行为，不是 bug。所有“获取”类方法（getMonth、getDate、getHours）都按本地时区返回原始值，而“设置”类方法（setMonth、setDate）也按本地时区解释参数。
-
getMonth()返回 0 表示一月，所以显示时要date.getMonth() + 1 -
getDate()是当月第几天（1～31），不是“日期对象”，别和Date构造函数混淆 - 需要 UTC 时间？用
getUTCFullYear()、getUTCMonth()等对应方法，但注意：它们仍返回 0～11 的月份
如何安全地加减 7 天，而不受夏令时或月末影响？
直接改毫秒（date.getTime() + 7 * 24 * 60 * 60 * 1000）看似简单，但在夏令时切换日可能多/少 1 小时；用 setDate(date.getDate() + 7) 更可靠，因为它基于日历逻辑，自动处理跨月（比如 1 月 30 日 + 5 天 → 2 月 4 日）。
立即学习“Java免费学习笔记（深入）”；
- 加减天数：用
setDate()，不要碰毫秒 - 加减月份：用
setMonth(date.getMonth() + n)，它会自动归整日期（如 1 月 31 日 + 1 月 → 2 月 28 日或 29 日） - 避免
setFullYear()单独调用，它不会自动修正日期，比如new Date(2023, 1, 30).setFullYear(2024)会变成 2024-03-01（因为 2 月没 30 日，溢出到 3 月）
toLocaleDateString() 格式千差万别，怎么写出稳定输出？
这个方法依赖运行环境的语言和地区设置，en-US 下是 10/1/2023，zh-CN 下是 2023年10月1日，连年份是否补零都不统一。它适合展示给用户看，但不适合做计算或存档。
- 需要固定格式（如
YYYY-MM-DD）？自己拼接：${d.getFullYear()}-${String(d.getMonth() + 1).padStart(2, '0')}-${String(d.getDate()).padStart(2, '0')} - 需要兼容 IE？别用
toLocaleString(options)的year: 'numeric'这类选项，IE 不支持，老老实实手动格式化 - 需要时区信息？
toLocaleString('en', { timeZone: 'Asia/Shanghai' })可以强制指定，但注意：不是所有环境都支持 IANA 时区名（尤其旧安卓 WebView）
最麻烦的从来不是“怎么得到今天”，而是“怎么让昨天在东京和昨天在纽约都指向同一个日历日”。原生 Date 没有日历日抽象，只有时间戳+时区偏移。一旦涉及业务上的“工作日”“自然月”“财报周期”，就得靠库或自定义逻辑兜底。
