17370845950

JavaScript 处理日期时，时区问题是最容易出错的部分。核心陷阱在于：Date 对象内部始终以 UTC 时间戳（毫秒）存储，但多数构造和格式化方法默认使用本地时区，而部分 API（如 toUTCString()、toISOString()）又强制走 UTC——这种隐式切换极易导致时间偏移、重复解析、跨天错误。

陷阱一：字符串构造自动绑定本地时区

当你写 new Date('2025-05-20') 或 new Date('2025-05-20T10:00')，JS 会把该字符串当作本地时区时间解析（即使没写时区）。例如在中国运行，'2025-05-20' 实际被解释为 2025-05-20T00:00:00+08:00，对应 UTC 时间是前一日 16:00。

• ✅ 安全做法：显式带时区，如 new Date('2025-05-20T00:00:00Z')（Z 表示 UTC）或 '2025-05-20T00:00:00+00:00'
• ✅ 或用时间戳构造：new Date(1716192000000)（完全规避解析歧义）
• ❌ 避免：new Date('2025-05-20')、new Date('2025/05/20')、new Date('2025-05-20 10:00')

陷阱二：toLocaleString() 看似“友好”，实则不可控

date.toLocaleString() 会根据用户浏览器语言和地区设置自动选择格式和时区，同一段代码在东京和纽约可能输出不同日期（尤其跨日边界时），无法保证一致性。

• ✅ 需要本地显示时，明确指定时区：date.toLocaleString('zh-CN', { timeZone: 'Asia/Shanghai' })
• ✅ 服务端交互或日志记录，优先用 date.toISOString()（固定 UTC ISO 格式）
• ❌ 不要依赖默认无参数的 toLocaleString() 做逻辑判断或存储

陷阱三：getHours() / setHours() 操作的是本地时间，不是 UTC

date.getHours() 返回的是当前系统时区下的小时数，不是 UTC 小时。若你用它做“每天上午9点触发”的逻辑，在不同时区机器上行为完全不同。

• ✅ 要操作 UTC 时间，用 getUTCHours()、setUTCHours() 等 UTC 系列方法
• ✅ 更稳妥：统一用 UTC 时间戳计算，例如“今天 UTC 9 点” = new Date().setUTCHours(9,0,0,0)
• ❌ 不要混合使用：date.setHours(9) 后再调 date.getUTCHours()——结果取决于本地偏移，不可预测

陷阱四：夏令时（DST）导致的“时间消失”或“重复”

在实行夏令时的地区（如美国东部时间），每年有两天会出现问题：春季“跳过”1 小时（如 2:00 → 3:00），秋季“重复”1 小时（如 2:00 → 2:00）。此时 new Date('2025-03-10T02:30') 可能被纠正为 3:30 或静默失败。

• ✅ 关键业务（如定时任务、预约系统）避免依赖模糊的本地时间点
• ✅ 使用 UTC 时间戳驱动逻辑，显示时再按需转换时区
• ✅ 利用 Intl.DateTimeFormat 的 timeZoneName: 'short' 显示当前是否 DST（如 CST/CDT）

不复杂但容易忽略：只要记住“Date 对象本身不存时区，只存毫秒；所有带‘本地’字样的方法都受系统影响，所有带‘UTC’字样的方法才真正可控”，就能避开八成时区坑。