JavaScript Date对象本质是毫秒时间戳包装器，所有方法基于Unix纪元毫秒值计算；格式化应手动提取字段并补零，优先使用toISOString()获取标准UTC字符串，时区处理需明确意图。
JavaScript 日期对象本质是时间戳包装器
JavaScript 的 Date 对象不是“真正的时间结构”，它内部只存一个 number：从 Unix 纪元（1970-01-01T00:00:00Z）到当前时刻的毫秒数。所有方法（如 getHours()、toISOString()）都是基于这个毫秒值，再按本地时区或 UTC 做计算得出的视图。
这意味着：new Date('2023-10-05') 和 new Date(1696444800000) 在内存中完全等价；而 toString() 显示的“本地时间”只是格式化结果，不改变底层毫秒值。
不要用 toLocaleString() 直接拼接格式
很多人用 date.toLocaleString('zh-CN', { year: 'numeric', month: '2-digit' }) 拼字符串，但它的输出高度依赖用户系统语言、时区和浏览器实现——同一段代码在 macOS Safari 和 Windows Edge 上可能返回 "2023/10/05" 或 "2023-10-05"，甚至月份名变成中文“十月”。
更稳妥的做法是手动提取字段并补零：
立即学习“Java免费学习笔记（深入）”；
const d = new Date();
const y = d.getFullYear();
const m = String(d.getMonth() + 1).padStart(2, '0');
const day = String(d.getDate()).padStart(2, '0');
const formatted = `${y}-${m}-${day}`; // 稳定输出 YYYY-MM-DD-
getMonth()返回 0–11，必须加 1 -
padStart(2, '0')比slice(-2)更可靠（避免负数意外） - 如果需要 UTC 时间，改用
getUTCFullYear()、getUTCMonth()等
ISO 8601 格式优先用 toISOString()，而非 toUTCString()
toISOString() 总是返回形如 "2023-10-05T08:12:34.567Z" 的标准字符串，时区固定为 UTC，且带毫秒、严格 24 小时制，适合 API 通信或日志记录。
toUTCString() 返回类似 "Thu, 05 Oct 2023 08:12:34 GMT"，是 RFC 7231 格式，可读性好但字段顺序和缩写不统一，解析困难。
- 后端通常只认
toISOString()输出（尤其 Node.js 的JSON.stringify(new Date())默认调它） - 若需去掉毫秒，可用
toISOString().slice(0, 19) + 'Z' - 注意：
toISOString()强制转 UTC，new Date('2023-10-05').toISOString()实际表示的是你本地时区的午夜对应 UTC 时间，不是字面“2023-10-05T00:00:00Z”
时区处理是最大陷阱，没有“绝对正确”的格式化函数
所谓“今天是几号”，取决于你指哪一地的“今天”。new Date().getDate() 是本地时区的日期，new Date().getUTCDate() 是 UTC 日期，二者在跨时区场景下可能差一天。
常见错误：
- 用
new Date('2023-10-05')解析字符串 → 浏览器按本地时区解释，中国用户得到的是2023-10-05T00:00:00+08:00，而美国用户是2023-10-05T00:00:00-04:00，底层毫秒值不同 - 把用户输入的
"2023-10-05"直接传给Date构造函数 → 应先补全为"2023-10-05T00:00:00"再解析，或用new Date(Date.parse('2023-10-05') + new Date().getTimezoneOffset() * 60000)强制对齐本地午夜 - 依赖
toLocaleDateString()显示“今日” → 它会随系统设置变化，无法用于逻辑判断
真正安全的起点永远是明确时区意图：你要的是用户本地时间？服务器所在时区？还是全球统一的 UTC 日历日？选错起点，后面所有格式化都可能偏移。
