Date对象仅存UTC毫秒数，但构造和方法默认依赖本地时区：字符串解析跨浏览器不一致，getter返回本地值，需用getUTC*系列获取UTC时间，序列化应优先使用toISOString()。
JavaScript 的 Date 对象本身不存储时区信息，它只保存一个毫秒数（自 UTC 1970-01-01 00:00:00 起），但几乎所有构造、格式化和获取方法都隐式依赖宿主环境的本地时区——这是绝大多数问题的根源。
构造 Date 时传入字符串极易掉进时区陷阱
传入形如 "2023-10-05" 或 "2023-10-05T12:00:00" 的字符串时，不同浏览器行为不一致：
-
"2023-10-05"（无时间部分）：Chrome / Firefox / Safari 全部按 UTC 零点解析 →new Date("2023-10-05")实际表示 UTC 时间2023-10-05T00:00:00Z，再转成本地时间显示（比如东八区就显示为2023-10-05T08:00:00） -
"2023-10-05T12:00:00"（无时区标识）：Chrome 当作本地时间，Safari 和 Firefox 当作 UTC 时间 —— 这是真实存在的跨浏览器差异 - 唯一可靠的是带完整时区偏移的 ISO 字符串：
"2023-10-05T12:00:00+08:00"或"2023-10-05T04:00:00Z"
new Date("2023-10-05"); // ⚠️ 行为不统一，避免使用
new Date("2023-10-05T00:00:00Z"); // ✅ 明确 UTC，安全
new Date(2023, 9, 5); // ✅ 使用数值构造（注意月份从 0 开始）
getHours() / getFullYear() 等方法返回的是本地时间值
哪怕你用 new Date("2023-10-05T00:00:00Z") 创建了一个明确的 UTC 时间，调用 getHours() 仍返回你本机时区的小时数。这不是 bug，是设计如此 —— Date 对象内部是 UTC 毫秒数，但这些 getter 是“本地视图”。
- 想取 UTC 值？必须用
getUTCHours()、getUTCFullYear()等对应方法 - 混淆
getHours()和getUTCHours()是最常见逻辑错误，尤其在做跨时区调度或服务端时间比对时 - 序列化输出也需注意：
toString()返回本地格式，toISOString()才返回标准 UTC ISO 字符串
const d = new Date("2023-10-05T00:00:00Z");
d.getHours(); // → 8（如果你在东八区）
d.getUTCHours(); // → 0（这才是原始含义）
d.toISOString(); // → "2023-10-05T00:00:00.000Z"
toJSON() 和 Date.parse() 的隐式规则容易误判
toJSON() 内部调用 toISOString()，所以它总是返回 UTC 字符串；但 Date.parse() 解析字符串时，又回到前面说的歧义问题。
立即学习“Java免费学习笔记（深入）”；
-
Date.parse("2023-10-05")在 Chrome 返回1696444800000（UTC 00:00），在 Safari 可能返回1696416000000（本地 00:00） - 不要用
Date.parse()解析用户输入或 API 返回的时间字符串，改用new Date(str).getTime()并配合校验，或直接用Intl.DateTimeFormat解析 -
后端返回时间字段，优先要求其带时区（如
"2023-10-05T12:00:00+08:00"），而不是裸字符串
真正麻烦的不是语法难，而是所有方法名都不显式带 “local” 或 “utc” 标识，仅靠文档约定区分；加上控制台打印 Date 对象时默认显示本地时间，让人误以为“它就是本地时间对象”。一旦涉及跨时区协作、定时任务、日志时间对齐，这些隐式行为就会突然暴露出来。
