JavaScript日期处理关键在于区分本地显示与UTC存储，优先使用ISO 8601（如'2024-05-20T14:30:00Z'）或时间戳创建Date对象，读取时用toISOString()获取UTC、toLocaleString()显示本地时间，并统一前后端时间传递为UTC格式。
JavaScript 的日期处理本身不难，但时区问题容易出错——关键不在“怎么写”，而在“怎么想”。核心原则是：始终区分“本地时间显示”和“UTC 时间存储/传输”，避免用 new Date() 直接解析带时区的字符串，优先使用 ISO 8601 格式（如 '2024-05-20T14:30:00Z'）或明确指定时区。
用 Date 对象安全创建和读取时间
浏览器中 Date 内部始终以毫秒数（UTC 时间戳）存储，但构造和格式化方法默认绑定本地时区，这是混乱源头。
- 创建时尽量用 UTC 时间戳或 ISO 字符串（末尾带
Z表示 UTC）：new Date('2024-05-20T14:30:00Z')—— 这个时间在任何时区都代表同一时刻；new Date(1716215400000)—— 毫秒时间戳也绝对可靠。 - 避免用字符串直接构造含时区偏移的非标准格式，比如
new Date('2024-05-20 14:30+0800')，不同浏览器解析行为可能不一致。 - 读取时间时，用
.toISOString()获取标准 UTC 字符串；用.toLocaleString()显示本地时间（可传{ timeZone: 'Asia/Shanghai' }指定目标时区）。
手动转换时区：不依赖库也能做对
有时只需简单换算（比如把服务器返回的 UTC 时间转为用户本地时间），不必引入完整库。
- 已知一个 UTC 时间（如
new Date('2024-05-20T14:30:00Z')），要显示为东京时间：date.toLocaleString('ja-JP', { timeZone: 'Asia/Tokyo' }) - 要把用户输入的“北京时间下午3点”转成 UTC 时间戳：
先用new Date('2024-05-20T15:00:00+0800')构造（显式声明 +0800），再调用.getTime()得到 UTC 毫秒数。 - 注意：
getHours()、getMinutes()等方法返回的是**本地时区值**；要用getUTCHours()、getUTCMinutes()才能拿到原始 UTC 值。
跨系统交互：统一用 UTC + 显式时区标识
前后端、数据库、API 之间传递时间，必须约定规则，否则必踩坑。
立即学习“Java免费学习笔记（深入）”；
- 后端返回时间字段，应统一为 ISO 8601 UTC 字符串（结尾带
Z），例如："created_at": "2024-05-20T06:30:00Z"。 -
前端接收后，直接
new Date(response.created_at)即可得到准确时间对象；显示时再按需格式化为用户所在时区。 - 用户选择时间（如日历组件），提交前务必转成 UTC 字符串（
date.toISOString()）再发给后端，而不是用date.toString()或date.toLocaleString()。
进阶需求：用 Intl.DateTimeFormat 精确控制格式与时区
原生 API 已足够应对多数场景，无需立刻上 moment 或 date-fns。
- 格式化任意时区时间：
new Intl.DateTimeFormat('zh-CN', {
year: 'numeric', month: '2-digit', day: '2-digit',
hour: '2-digit', minute: '2-digit',
timeZone: 'America/New_York'
}).format(date) - 获取当前时区名称（如 'CST' 或 'PDT'）：
Intl.DateTimeFormat().resolvedOptions().timeZone—— 返回 'Asia/Shanghai' 这类 IANA 时区名，可用于后续格式化。 - 对比两个时区的当前时间差（动态）：
分别用Intl.DateTimeFormat格式化同一时间戳，看小时分钟差异即可，比手动算偏移更可靠。
