JavaScript Date对象内部只存UTC时间戳，但方法默认按本地时区解析；创建时需用带Z或偏移的ISO字符串，显示时应明确时区并用Intl.DateTimeFormat等可控方式处理，存取数据必须统一用UTC。
JavaScript 的 Date 对象本身不存储时区信息，它内部只保存一个毫秒数（自 1970-01-01T00:00:00Z 起的 UTC 时间戳），但很多方法（如 getHours()、toString()）默认按**本地时区**解释；而另一些方法（如 getUTCHours()、toUTCString()）则明确操作 UTC。时区问题的核心在于：你是否清楚当前 Date 对象被当作“本地时间”还是“UTC 时间”来解析和显示。
创建日期时小心字符串格式——时区隐含规则很关键
用字符串构造 Date 对象时，浏览器会按规范自动推断时区，但不同格式结果完全不同：
- 带时区偏移的字符串（如
"2024-05-20T14:30:00+08:00"或"2024-05-20T14:30:00Z"）→ 解析为对应 UTC 时间 - 纯日期格式（如
"2024-05-20"）→ 在 Chrome/Firefox/Safari 中按 UTC 解析（即变成2024-05-20T00:00:00Z），但 IE 视为本地时间 —— 这是最大兼容陷阱 - 带时间但无偏移（如
"2024-05-20 14:30:00"）→ 全部按本地时区解析
✅ 建议：统一使用带 Z（UTC）或显式偏移（如 +08:00）的 ISO 8601 字符串；避免 "YYYY-MM-DD" 单独使用。需要本地零点？手动构造：new Date(year, month, date)。
显示时间前必须明确“想展示给用户的是哪个时区”
不要依赖 date.toString() 或 date.toLocaleString() 默认行为——它们受用户系统设置影响，不可控。
立即学习“Java免费学习笔记（深入）”；
- 要显示用户本地时间 → 用
date.toLocaleString('zh-CN')（可选 locale 和 options） - 要固定显示东八区时间 → 先转成 UTC 时间戳，再手动加 8 小时偏移计算，或用
Intl.DateTimeFormat指定时区：new Intl.DateTimeFormat('zh-CN', { timeZone: 'Asia/Shanghai' }).format(date) - 要显示 UTC 时间 → 用
date.toUTCString()或date.getUTCFullYear() + '...'手动拼
跨时区计算（比如“北京时间上午9点对应的纽约时间”）别手算偏移
时区偏移不是固定值（夏令时存在！），不能简单 ±x 小时。正确做法是：用同一个时间戳，在不同 timeZone 下格式化。
- 例如：已知一个时间（如用户提交的“2024-06-01T09:00:00+08:00”），想展示对应纽约时间：
const date = new Date("2024-06-01T09:00:00+08:00");const nyTime = new Intl.DateTimeFormat('en-US', { timeZone: 'America/New_York' }).format(date); - 后端传来的 ISO 字符串（如
"2024-06-01T09:00:00Z"）天然是 UTC，可直接用于多时区渲染
存取数据时，前后端约定必须统一为 UTC
数据库、API 接口、日志时间一律用 UTC 字符串（toISOString() 输出）或时间戳（date.getTime()）。前端展示时再按需转换——这是避免混乱的铁律。
- 发请求前：把用户选择的本地时间转成 UTC 存储
const utcStr = userDate.toISOString(); // 自动转成 Z 结尾 - 收响应后：拿到 UTC 字符串直接 new Date()，它就是准确的时间戳，后续展示交给
Intl或手动 UTC 方法 - 避免：把本地时间字符串（如
"2024-05-20 14:30"）直接发给后端
基本上就这些。不复杂但容易忽略——关键是每次创建、显示、传输日期时，心里默念一句：“这个值，此刻代表的是哪个时区下的时间？”
