17370845950

JavaScript Date对象默认按本地时区解析字符串，构造方式差异大：new Date('2025-10-05')解析为UTC导致偏移，new Date('2025/10/05')或new Date(2025,9,5)更安全；get/set方法默认操作本地时间，UTC需用getUTC/setUTC；toISOString()/toJSON()返回UTC字符串，toString()返回本地格式；跨时区场景应优先使用时间戳或显式时区声明。

JavaScript 的 Date 对象不是“拿来就能用”的时间工具，它默认按本地时区解析字符串、构造方式稍有差异就容易出错，尤其在跨时区、格式化、计算差值等场景下。

new Date() 构造函数的几种写法差异很大

传参不同，行为完全不同：不加参数返回当前时间；传字符串可能被当成 UTC 或本地时间（取决于格式）；传数字是毫秒时间戳；传多个数字参数则是本地时间（注意月份从 0 开始）。

• new Date() → 当前本地时间
• new Date('2025-10-05') → 解析为 UTC 时间（即 2025-10-05T00:00:00Z），再转成本地时区显示，常导致“少一天”错觉
• new Date('2025/10/05') → 按本地时区解析，更安全
• new Date(2025, 9, 5) → 本地时间 2025 年 10 月 5 日（月份是 0~11）
• new Date(1696444800000) → 毫秒时间戳，对应 UTC 时间

getXXX() 和 setXXX() 方法默认都是本地时区

所有 getDate()、getHours()、setMonth() 等方法操作的都是**当前系统本地时区**的时间值。如果需要 UTC 时间，必须显式使用 getUTCDate()、setUTCHours() 等对应方法。

• 想获取 2025-10-05 14:30:00 UTC 的小时？用 date.getUTCHours()，不是 date.getHours()
• date.setDate(1) 修改的是本地日期，可能影响 UTC 日期（比如你在东八区设为 1 号，UTC 就是上月 31 号）
• 跨天计算（如“明天此时”）推荐用毫秒加减：new Date(date.getTime() + 24 * 60 * 60 * 1000)，比 setDate(getDate()+1) 更可靠

toJSON() 和 toISOString() 返回的是 UTC 字符串

这两个方法都返回形如 "2025-10-05T06:30:00.000Z" 的 ISO 8601 UTC 字符串，常用于 API 通信或存储。但要注意：toString()、toLocaleString() 返回的是本地格式，混用会导致时区混乱。

const d = new Date('2025-10-05T14:30:00');
console.log(d.toISOString()); // "2025-10-05T06:30:00.000Z"（UTC）
console.log(d.toString());    // "Thu Oct 05 2025 14:30:00 GMT+0800 (CST)"（本地）
console.log(d.toJSON());      // 同 toISOString()

• 后端通常期望 toISOString() 输出，别误用 toString()
• JSON.stringify(new Date()) 会自动调用 toJSON()，所以序列化后是 UTC 字符串
• 从后端拿到 ISO 字符串（含 Z）再 new Date()，结果仍是本地时间对象——只是它的内部毫秒值对齐了 UTC

时区处理最易忽略的坑：字符串构造 vs 时间戳构造

这是生产环境最常引发日期偏移的点。比如用户输入 "2025-10-05"，直接 new Date("2025-10-05") 在 Chrome 和 Safari 行为一致（UTC），但在某些旧版浏览器或 Node.js 版本中可能按本地解析。稳妥做法是统一转成时间戳或强制指定时区。

• 避免直接解析带短横线的日期字符串：new Date("2025-10-05")
• 改用斜杠格式：new Date("2025/10/05")（明确本地）
• 或手动拆解：new Date(2025, 9, 5)
• 或用 Date.parse("2025-10-05T00:00:00Z") 显式声明 UTC，再 new Date()

时区不是附加属性，而是 Date 对象内部毫秒值与本地显示之间的映射关系——一旦构造错误，后续所有 get/set 都建立在错误基础上。