JavaScript处理日期时间应明确原始时区，优先用UTC方法计算和存储，显示时按需格式化；构造用ISO格式或显式参数；前后端统一用带时区的ISO字符串或UTC时间戳。
JavaScript 处理日期和时间的核心是 Date 对象，但它默认基于本地时区，容易在跨时区场景下出错。关键在于：**明确时间的原始时区含义，再决定用本地时间、UTC 还是特定时区格式展示或计算。**
用 Date 构造和解析要小心时区隐含行为
Date 构造函数对字符串的解析规则复杂，不同格式触发不同默认时区：
- 带连字符的日期（如
"2025-05-20"）→ 解析为 UTC 时间，再转成本地时区显示 - 带斜杠的日期（如
"05/20/2025"）→ 直接按本地时区解析 - 带时区信息的字符串（如
"2025-05-20T10:00:00+08:00"或"2025-05-20T02:00:00Z"）→ 严格按所给时区转换为内部毫秒数
建议统一使用 ISO 8601 格式（带 Z 或偏移量）
，或用 new Date(year, monthIndex, day, hour, minute, second) 显式构造本地时间。
获取时间值优先用 UTC 方法避免本地时区干扰
当需要做时间计算（如加减天数、比较先后）、存储或传输时，应尽量操作 UTC 值，防止夏令时或本地设置影响结果：
- 用
date.getUTCFullYear()、date.getUTCHours()等代替getFullYear()、getHours() - 用
date.getTime()获取时间戳（始终是 UTC 毫秒数），它是最安全的中间表示 - 创建“今天零点”的 UTC 时间：
new Date(Date.now() - (new Date()).getTimezoneOffset() * 60000)不可靠；推荐：new Date(new Date().toUTCString().split(' ')[0] + ' 00:00:00 GMT')或更稳妥地用new Date(Date.UTC(year, month, day))
显示给用户时按需格式化，别硬套本地时区
用户看到的时间应该符合其所在地区习惯，但不能简单依赖 toLocaleString() 的默认行为：
- 若后端返回的是 UTC 时间戳，前端想显示用户本地时间：直接
new Date(timestamp).toLocaleString()即可（浏览器自动处理） - 若需固定显示某一时区（如“北京时间”），不能只靠
toLocaleString({ timeZone: 'Asia/Shanghai' })（兼容性有限，IE 不支持）；生产环境建议用轻量库如 Luxon 或 Day.js + timezone 插件 - 简单兼容方案：手动加减偏移量（不推荐用于精确业务），例如把 UTC 时间转为东八区显示：
const utc = new Date(); const beijing = new Date(utc.getTime() + 8 * 60 * 60 * 1000);（注意夏令时问题，此法有风险）
与后端协作时约定好时间基准
时区混乱大多源于前后端理解不一致：
- 后端 API 应统一返回 ISO 8601 字符串，并带时区信息（如
"2025-05-20T12:00:00+08:00"或"2025-05-20T04:00:00Z"），前端new Date(str)可正确解析 - 前端提交时间前，明确是传本地时间还是 UTC 时间。推荐统一传 UTC（如
date.toISOString()），由后端处理时区逻辑 - 避免传只有日期没有时间的字符串（如
"2025-05-20"），它在不同环境可能被解释为不同 UTC 时间
