Date对象仅存UTC毫秒数，但构造和方法默认依赖本地时区：字符串解析跨浏览器不一致，getter返回本地值，需用getUTC*系列获取UTC时间，序列化应优先使用toISOString()。

JavaScript 的 Date 对象本身不存储时区信息，它只保存一个毫秒数（自 UTC 1970-01-01 00:00:00 起），但几乎所有构造、格式化和获取方法都隐式依赖宿主环境的本地时区——这是绝大多数问题的根源。

构造 Date 时传入字符串极易掉进时区陷阱

传入形如 "2025-10-05" 或 "2025-10-05T12:00:00" 的字符串时，不同浏览器行为不一致：

• "2025-10-05"（无时间部分）：Chrome / Firefox / Safari 全部按 UTC 零点解析 → new Date("2025-10-05") 实际表示 UTC 时间 2025-10-05T00:00:00Z，再转成本地时间显示（比如东八区就显示为 2025-10-05T08:00:00）
• "2025-10-05T12:00:00"（无时区标识）：Chrome 当作本地时间，Safari 和 Firefox 当作 UTC 时间 —— 这是真实存在的跨浏览器差异
• 唯一可靠的是带完整时区偏移的 ISO 字符串："2025-10-05T12:00:00+08:00" 或 "2025-10-05T04:00:00Z"

new Date("2025-10-05");           // ⚠️ 行为不统一，避免使用
new Date("2025-10-05T00:00:00Z"); // ✅ 明确 UTC，安全
new Date(2025, 9, 5);             // ✅ 使用数值构造（注意月份从 0 开始）

getHours() / getFullYear() 等方法返回的是本地时间值

哪怕你用 new Date("2025-10-05T00:00:00Z") 创建了一个明确的 UTC 时间，调用 getHours() 仍返回你本机时区的小时数。这不是 bug，是设计如此 —— Date 对象内部是 UTC 毫秒数，但这些 getter 是“本地视图”。

• 想取 UTC 值？必须用 getUTCHours()、getUTCFullYear() 等对应方法
• 混淆 getHours() 和 getUTCHours() 是最常见逻辑错误，尤其在做跨时区调度或服务端时间比对时
• 序列化输出也需注意：toString() 返回本地格式，toISOString() 才返回标准 UTC ISO 字符串

const d = new Date("2025-10-05T00:00:00Z");
d.getHours();     // → 8（如果你在东八区）
d.getUTCHours();  // → 0（这才是原始含义）
d.toISOString();  // → "2025-10-05T00:00:00.000Z"

toJSON() 和 Date.parse() 的隐式规则容易误判

toJSON() 内部调用 toISOString()，所以它总是返回 UTC 字符串；但 Date.parse() 解析字符串时，又回到前面说的歧义问题。

• Date.parse("2025-10-05") 在 Chrome 返回 1696444800000（UTC 00:00），在 Safari 可能返回 1696416000000（本地 00:00）
• 不要用 Date.parse() 解析用户输入或 API 返回的时间字符串，改用 new Date(str).getTime() 并配合校验，或直接用 Intl.DateTimeFormat 解析
• 后端返回时间字段，优先要求其带时区（如 "2025-10-05T12:00:00+08:00"），而不是裸字符串

真正麻烦的不是语法难，而是所有方法名都不显式带 “local” 或 “utc” 标识，仅靠文档约定区分；加上控制台打印 Date 对象时默认显示本地时间，让人误以为“它就是本地时间对象”。一旦涉及跨时区协作、定时任务、日志时间对齐，这些隐式行为就会突然暴露出来。