JavaScript Date对象需谨慎处理时区与格式：ISO格式字符串被解析为UTC，斜杠格式按本地时区；应优先使用数值构造或UTC方法；加减天数用setDate()而非毫秒运算；toLocaleString()须显式指定locale。
JavaScript 的 Date 对象不是“拿来就能用”的时间工具，它默认按本地时区解析字符串、构造时易出错、获取值需手动调用方法——不主动处理时区和格式，几乎必然踩坑。
构造 Date 时为什么 new Date('2023-10-01') 和 new Date('2023/10/01') 行为不同？
这是最常被忽略的兼容性陷阱：ISO 格式（'YYYY-MM-DD'）会被强制当作 UTC 时间解析，而斜杠格式（'YYYY/MM/DD'）按本地时区解析。
-
new Date('2023-10-01')→ 实际创建的是2023-10-01T00:00:00.000Z（UTC 零点），在东八区显示为Sun Oct 01 2023 08:00:00 GMT+0800 -
new Date('2023/10/01')→ 按本地时区解析，结果是当天 00:00:00 本地时间，无偏移歧义 - 推荐写法：
new Date(2023, 9, 1)（注意月份从 0 开始）或new Date(Date.UTC(2023, 9, 1))显式控制时区
getYear()、getFullYear()、getUTCFullYear() 到底该用哪个？
getYear() 已废弃，返回两位年份（如 2023 → 123），绝对不要用。日常开发中只应考虑两个场景：
- 要显示给用户看的年份 → 用
getFullYear()（本地时区） - 做跨时区计算或存储（如后端要求 UTC 时间）→ 用
getUTCFullYear()、getUTCMonth()、getUTCDate()等整套 UTC 方法 - 混用本地与 UTC 方法会导致日期错位，例如
date.getFullYear() + '-' + (date.getUTCMonth() + 1)是典型错误
如何安全地加减天数而不受夏令时或月末影响？
直接改 date.setDate(date.getDate() + n) 是唯一可靠方式。避免用毫秒加减（date.getTime() + n * 24 * 60 * 60 * 1000），因为夏令时切换日会导致 ±1 小时偏差。
立即学习“Java免费学习笔记（深入）”；
const d = new Date('2023-10-28'); // 欧洲夏令时结束日
d.setDate(d.getDate() + 1); // ✅ 正确：得到 '2023-10-29'
// d.setTime(d.getTime() + 24 * 60 * 60 * 1000); // ❌ 可能跳到 2023-10-30 或卡在 29 日 23:00- 月份加减同理：用
setMonth(date.getMonth() + n)，它会自动处理 1月→2月、12月→下一年等边界 - 不要依赖
toDateString()或toISOString()做运算，它们只是格式化输出，不改变原始值
为什么 toLocaleString() 在不同浏览器或系统上输出差异很大？
它完全依赖宿主环境的区域设置（Intl 数据），连中文简体在 Chrome 和 Safari 上都可能一个出「2023年10月1日」、一个出「2023/10/01」。生产环境必须显式传参：
new Date().toLocaleString('zh-CN', {
year: 'numeric',
month: '2-digit',
day: '2-digit',
hour: '2-digit',
minute: '2-digit',
second: '2-digit',
hour12: false
});
// → "2023/10/01 14:30:45"- 服务端渲染（SSR）或 Node.js 环境中，
toLocaleString()可能 fallback 到 en-US，务必指定 locale - 需要 ISO 格式且带本地时区偏移 → 用
date.toString()；只要纯 UTC ISO → 用date.toISOString()
真正麻烦的从来不是“有没有方法”，而是每个方法背后藏着时区、解析规则、历史兼容性三重暗礁。哪怕只是显示一个“3天前”，也要先决定：这个“3天”是按用户本地日历算，还是按服务器 UTC 时间算——选错起点，后面全错。
