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')
（Z 表示 UTC）或 陷阱二：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’字样的方法才真正可控”，就能避开八成时区坑。
