JavaScript Date解析ISO格式字符串（如"2025-10-01"）默认按UTC处理，再转为本地时区显示，故北京用户看到早8小时；安全写法是显式指定时区或用斜杠格式。
JavaScript Date 对象默认使用本地时区，但解析字符串时行为不一致——"2025-10-01" 被当作 UTC，而 "2025/10/01" 被当
作本地时间。这是绝大多数时区 bug 的根源。
为什么 new Date("2025-10-01") 返回的时间比预期早 8 小时？
ECMAScript 规定：ISO 格式（YYYY-MM-DD 或带时间的 YYYY-MM-DDTHH:mm:ss）字符串，若无时区标识（如 Z 或 +08:00），**一律按 UTC 解析**，再转成本地时区显示。你看到的“早 8 小时”，其实是 UTC 时间 2025-10-01T00:00:00Z → 北京时间 2025-10-01T08:00:00。
- ✅ 安全写法：
new Date("2025-10-01T00:00:00+08:00")（显式指定时区） - ✅ 兼容写法：
new Date("2025/10/01")（斜杠格式强制按本地时区解析） - ❌ 危险写法：
new Date("2025-10-01")（无时区、ISO 格式 → 默认 UTC） - ⚠️ 注意：
new Date(2025, 9, 1)是安全的（月份从 0 开始，但构造函数参数始终按本地时区处理）
如何可靠地获取当前东八区（北京时间）时间戳？
不要依赖 new Date().getTime() 后手动加减，因为 getTime() 返回的是毫秒级 Unix 时间戳（UTC 基准），它本身没有时区。所谓“北京时间时间戳”就是 UTC 时间戳，只是你在展示时需按 +08:00 格式化。
- 获取时间戳（UTC 基准，全球唯一）：
new Date().getTime() - 格式化为北京时间字符串（自动适配本地时区显示）：
new Date().toLocaleString("zh-CN", { timeZone: "Asia/Shanghai" }) - 格式化为 ISO 字符串并强制 +08:00：
new Date().toLocaleString("sv-SE", { timeZone: "Asia/Shanghai" }).replace(/ /g, "T") + "+08:00" - 避免用
toTimeString()或toString()—— 它们返回本地时区字符串，但不带时区偏移标识，易误导
后端传来 "2025-10-01T12:00:00Z"，前端要按用户本地时区显示，怎么处理？
带 Z 的字符串明确表示 UTC 时间，Date 构造函数能正确识别。后续所有 getXXX() 方法（如 getHours()）返回的都是**本地时区值**；若需保持 UTC 上下文，必须用 getUTCXXX() 系列方法。
立即学习“Java免费学习笔记（深入）”；
const utcStr = "2025-10-01T12:00:00Z"; const d = new Date(utcStr);// 用户在北京：d.getHours() → 20（即北京时间 20:00） // 用户在纽约：d.getHours() → 8（即美东时间 08:00） // 但 d.getUTCHours() 始终是 12
// 安全输出用户本地时间： console.log(d.toLocaleString("zh-CN")); // 自动按用户系统时区格式化
- ✅ 正确：用
toLocaleString()+timeZone选项控制目标时区 - ✅ 正确：用
getUTCXXX()获取原始 UTC 值，用于计算或存储 - ❌ 错误：对
Date对象做setHours()后再调getHours()—— 会因 DST 或时区切换产生歧义 - ⚠️ 注意：
toLocaleString()的timeZone选项在旧版 Safari 中支持有限，生产环境建议 fallback 到Intl.DateTimeFormat
想彻底避开 Date 时区陷阱，有什么轻量替代方案？
原生 Date 不区分“时刻”和“日历日期”，也不提供不可变操作，导致大量隐式转换。简单项目可用 date-fns-tz，重度时区需求建议直接用 luxon（由 moment 团队开发，现代、轻量、API 清晰）。
-
luxon默认使用系统时区，但可随时切换：DateTime.fromISO("2025-10-01").setZone("Asia/Shanghai") - 所有输出方法（
toISO()、toLocaleString()）都显式声明时区意图，不会隐式转换 - 避免
moment-timezone—— 已进入维护模式，包体积大，API 设计陈旧 - 纯函数式替代（极简场景）：
new Date(Date.parse("2025-10-01") + new Date().getTimezoneOffset() * 60 * 1000)—— 仅适用于无时间部分的日期对齐，不推荐用于业务逻辑
最常被忽略的一点：时区问题往往不出现在构造 Date 时，而出现在跨时区比较、跨天计算、以及把 getHours() 结果误当作 UTC 值使用的时候。只要记住——Date 对象内部只存一个毫秒数（UTC 基准），其余全是展示层行为。
