JavaScript Date对象默认按本地时区解析字符串，构造方式差异大：new Date('2023-10-05')解析为UTC导致偏移，new Date('2023/10/05')或new Date(2023,9,5)更安全；get/set方法默认操作本地时间，UTC需用getUTC/setUTC；toISOString()/toJSON()返回UTC字符串，toString()返回本地格式；跨时区场景应优先使用时间戳或显式时区声明。
JavaScript 的 Date 对象不是“拿来就能用”的时间工具，它默认按本地时区解析字符串、构造方式稍有差异就容易出错，尤其在跨时区、格式化、计算差值等场景下。
new Date() 构造函数的几种写法差异很大
传参不同，行为完全不同：不加参数返回当前时间；传字符串可能被当成 UTC 或本地时间（取决于格式）；传数字是毫秒时间戳；传多个数字参数则是本地时间（注意月份从 0 开始）。
-
new Date()→ 当前本地时间 -
new Date('2023-10-05')→ 解析为 UTC 时间（即 2023-10-05T00:00:00Z），再转成本地时区显示，常导致“少一天”错觉 -
new Date('2023/10/05')→ 按本地时区解析，更安全 -
new Date(2023, 9, 5)→ 本地时间 2023 年 10 月 5 日（月份是 0~11） -
new Date(1696444800000)→ 毫秒时间戳，对应 UTC 时间
getXXX() 和 setXXX() 方法默认都是本地时区
所有 getDate()、getHours()、setMonth() 等方法操作的都是**当前系统本地时区**的时间值。如果需要 UTC 时间，必须显式使用 getUTCDate()、setUTCHours() 等对应方法。
- 想获取 2023-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 字符串
这两个方法都返回形如 "2023-10-05T06:30:00.000Z" 的 ISO 8601 UTC 字符串，常用于 API 通信或存储。但要注意：toString()、toLocaleString() 返回的是本地格式，混用会导致时区混乱。
立即学习“Java免费学习笔记（深入）”；
const d = new Date('2023-10-05T14:30:00');
console.log(d.toISOString()); // "2023-10-05T06:30:00.000Z"（UTC）
console.log(d.toString()); // "Thu Oct 05 2023 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 时间戳构造
这是生产环境最常引发日期偏移的点。比如用户输入 "2023-10-05"，直接 new Date("2023-10-05") 在 Chrome 和 Safari 行为一致（UTC），但在某些旧版浏览器或 Node.js 版本中可能按本地解析。稳妥做法是统一转成时间戳或强制指定时区。
- 避免直接解析带短横线的日期字符串：
new Date("2023-10-05") - 改用斜杠格式：
new Date("2023/10/05")（明确本地） - 或手动拆解：
new Date(2023, 9, 5) - 或用
Date.parse("2023-10-05T00:00:00Z")显式声明 UTC，再 new Date()
时区不是附加属性，而是 Date 对象内部毫秒值与本地显示之间的映射关系——一旦构造错误，后续所有 get/set 都建立在错误基础上。
