JavaScript Date对象四大坑：一、字符串构造默认本地时区解析，无偏移ISO串按UTC解析致日期偏差；二、getXXX()方法返回本地时间值，需用getUTCXXX()获取UTC值；三、格式化方法行为不一致且难定制，推荐Intl.DateTimeFormat或专业库；四、Date仅存毫秒数无时区属性，本质是时间点而非带时区时间。
JavaScript 的 Date 对象表面简单，实则暗藏多个易踩的坑，尤其在时区处理和格式化上。核心问题在于：它默认以本地时区解析字符串，但构造时又容易混淆 UTC 和本地时间；格式化方法（如 toString()、toLocaleString()）行为不一致且不可控；而现代标准（如 ISO 8601）的解析规则又与直觉不符。
坑一：字符串构造自动按本地时区解析，而非 UTC
当你写 new Date('2023-10-05')，浏览器会把它当作本地时区的午夜（例如北京时间是 2023-10-05T00:00:00+08:00），但写 new Date('2023-10-05T00:00:00')（无时区偏移）时，**规范要求按 UTC 解析** → 实际变成本地时间的前一日午夜（比如东八区就变成 2023-10-04T16:00:00）。这是最常导致“日期凭空少一天”的原因。
- ✅ 安全做法：显式指定时区，如
new Date('2023-10-05T00:00:00Z')（Z 表示 UTC）或'2023-10-05T00:00:00+08:00' - ✅ 更稳妥：用
Date.UTC()构造毫秒数再传入Date，例如new Date(Date.UTC(2023, 9, 5))（注意月份从 0 开始） - ❌ 避免：直接传纯日期字符串（如
'2023-10-05'）或无偏移的 ISO 时间字符串（如'2023-10-05T12:00:00'）
坑二：getXXX() 方法返回的是本地时间值，不是原始输入时间
date.getFullYear()、date.getDate() 等方法返回的永远是调用者所在**本地时区**对应的时间值。如果你用 new Date('2023-10-05T00:00:00Z') 创建了一个 UTC 时间，但在上海运行，date.getDate() 会返回 5（因为本地是 10 月 5 日 08:00），而实际 UTC 时间仍是 10 月 5 日 00:00 —— 这没问题；但若你本意是“取这个 UTC 时间的日期号”，那就得用 getUTCDate()。
- ✅ 记住口诀：“带 UTC 的方法操作 UTC 时间，不带的都操作本地时间”
- ✅ 处理服务器返回的 UTC 时间戳时，优先使用
getUTCFullYear()、getUTCHours()等 - ✅ 显示给用户看时，再用本地方法（如
toLocaleDateString()）做适配
坑三：格式化方法不可靠、不跨浏览器、难定制
date.toString() 输出格式完全由运行环境决定，中文系统可能带“GMT+0800 (中国标准时间)”，英文系统可能是 “PDT”；toJSON() 固定输出 UTC 的 ISO 字符串（末尾带 Z），但不含本地时区信息；toLocaleString() 虽支持 locale 和 options，但不同浏览器对 hour12、fractionalSecondDigits 等支持程度不一。
立即学习“Java免费学习笔记（深入）”；
- ✅ 生产环境避免直接拼接字符串（如
d.getFullYear() + '-' + (d.getMonth()+1)），容易漏补零、错时区 - ✅ 推荐使用成熟库（如
Intl.DateTimeFormat原生 API 或dayjs/luxon）做格式化 - ✅ 示例（原生）：
new Intl.DateTimeFormat('zh-CN', { dateStyle: 'medium', timeStyle: 'short' }).format(date)
坑四：Date 对象本身不存储时区，只存毫秒数
Date 实例本质是一个自 1970-01-01T00:00:00Z 起的毫秒数（timestamp），它**没有时区属性**。所谓“这个 Date 是 UTC 的”或“是北京时间的”，只是你创建它时的上下文，后续所有方法都基于该毫秒数 + 当前运行环境时区计算。因此，同一个 Date 对象，在东京和纽约调用 toString() 会输出不同字符串。
- ✅ 关键认知：Date 不是“带时区的时间”，而是“一个时间点”
- ✅ 存储/传输统一用 UTC 时间戳（number）或带 Z 的 ISO 字符串（string）
- ✅ 前端显示前，再根据用户时区或业务需求转换为本地时间或指定时区时间（可用
toLocaleString()或 luxon 的setZone()）
时区和格式化的坑，本质是混淆了“时间点”和“日历表示”。只要守住“存储用 UTC、显示按需转、构造必标时区”这三条线，就能避开大部分问题。不复杂但容易忽略。
