JavaScript Date对象需谨慎处理时区与格式：ISO格式字符串被解析为UTC，斜杠格式按本地时区；应优先使用数值构造或UTC方法；加减天数用setDate()而非毫秒运算；toLocaleString()须显式指定locale。

JavaScript 的 Date 对象不是“拿来就能用”的时间工具，它默认按本地时区解析字符串、构造时易出错、获取值需手动调用方法——不主动处理时区和格式，几乎必然踩坑。

构造 Date 时为什么 new Date('2025-10-01') 和 new Date('2025/10/01') 行为不同？

这是最常被忽略的兼容性陷阱：ISO 格式（'YYYY-MM-DD'）会被强制当作 UTC 时间解析，而斜杠格式（'YYYY/MM/DD'）按本地时区解析。

• new Date('2025-10-01') → 实际创建的是 2025-10-01T00:00:00.000Z（UTC 零点），在东八区显示为 Sun Oct 01 2025 08:00:00 GMT+0800
• new Date('2025/10/01') → 按本地时区解析，结果是当天 00:00:00 本地时间，无偏移歧义
• 推荐写法：new Date(2025, 9, 1)（注意月份从 0 开始）或 new Date(Date.UTC(2025, 9, 1)) 显式控制时区

getYear()、getFullYear()、getUTCFullYear() 到底该用哪个？

getYear() 已废弃，返回两位年份（如 2025 → 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 小时偏差。

const d = new Date('2025-10-28'); // 欧洲夏令时结束日
d.setDate(d.getDate() + 1); // ✅ 正确：得到 '2025-10-29'
// d.setTime(d.getTime() + 24 * 60 * 60 * 1000); // ❌ 可能跳到 2025-10-30 或卡在 29 日 23:00

• 月份加减同理：用 setMonth(date.getMonth() + n)，它会自动处理 1月→2月、12月→下一年等边界
• 不要依赖 toDateString() 或 toISOString() 做运算，它们只是格式化输出，不改变原始值

为什么 toLocaleString() 在不同浏览器或系统上输出差异很大？

它完全依赖宿主环境的区域设置（Intl 数据），连中文简体在 Chrome 和 Safari 上都可能一个出「2025年10月1日」、一个出「2025/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
});
// → "2025/10/01 14:30:45"

• 服务端渲染（SSR）或 Node.js 环境中，toLocaleString() 可能 fallback 到 en-US，务必指定 locale
• 需要 ISO 格式且带本地时区偏移 → 用 date.toString()；只要纯 UTC ISO → 用 date.toISOString()

真正麻烦的从来不是“有没有方法”，而是每个方法背后藏着时区、解析规则、历史兼容性三重暗礁。哪怕只是显示一个“3天前”，也要先决定：这个“3天”是按用户本地日历算，还是按服务器 UTC 时间算——选错起点，后面全错。