JavaScript Date对象无内置格式化方法，月份索引从0开始（5表示6月），应优先用ISO字符串构造、toLocaleDateString或Intl.DateTimeFormat格式化，避免手拼与毫秒硬算，跨月计算宜用date-fns/dayjs，时区需明确UTC处理。
JavaScript 的 Date 对象本身不提供内置格式化方法，直接调用 toString() 或拼接字符串极易出错——尤其涉及时区、月份索引从 0 开始、闰年、夏令时等隐性规则。别被“简单创建一个日期”误导，真正难的是让结果稳定可预期。
创建 Date 对象时，月份参数必须减 1
这是最常踩的坑：new Date(2024, 5, 1) 表示的是 **2024 年 6 月 1 日**，不是 5 月。因为月份（month）参数是 0～11 的索引值，0 = 一月，11 = 十二月。
常见错误场景：
- 从表单输入“2024-05-01”解析后直接传入
new Date(2024, 05, 01)→ 实际变成 6 月 - 用
getMonth()取值后未 +1 就显示给用户 → 总是少一个月
安全做法：
立即学习“Java免费学习笔记（深入）”；
- 优先用 ISO 字符串构造：
new Date('2024-05-01')（注意：必须是YYYY-MM-DD格式，带时区更稳） - 若需手动传参，明确注释：
new Date(year, monthIndex, day) // monthIndex: 0-based - 从
getMonth()获取值后显示前务必 +1
格式化日期别手写拼接，用 toLocaleDateString 或 Intl.DateTimeFormat
手写 date.getFullYear() + '-' + (date.getMonth()+1) + '-' + date.getDate() 看似简单，但会崩在：月份/日期没补零、时区偏移未处理、国际化需求（如日本要「2024年5月1日」）。
推荐方案：
- 快速本地化显示：
date.toLocaleDateString('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit' })→"2024-05-01" - 精确控制格式且兼容旧环境：
new Intl.DateTimeFormat('en-US', { month: 'short', day: 'numeric', year: 'numeric' }).format(date) - 避免
toISOString()直接用于展示——它返回 UTC 时间，用户看到的可能比本地时间早或晚若干小时
日期计算别用毫秒加减硬算，用专门库或封装函数处理边界
想“给今天加 30 天”，写 date.getTime() + 30 * 24 * 60 * 60 * 1000 是错的：忽略每月天数不同、闰秒、夏令时切换（某些地区某天只有 23 小时）。例如 2024 年 1 月 31 日 + 1 个月 ≠ 2024 年 2 月 31 日（根本不存在）。
实际建议：
- 简单偏移（如 +7 天）可用毫秒加减，但仅限“天”级且不跨月
- 跨月/年操作，用
setMonth()/setFullYear()，并配合getDate()检查是否溢出（如 1 月 31 日设为 2 月 → 自动变成 3 月 2 日） - 生产环境强烈建议用
date-fns（轻量）或dayjs（不可变）：比如addMonths(date, 1)内部已处理月末逻辑
时区问题不声明就默认本地时区，部署到服务器大概率出错
Node.js 环境下 new Date() 默认用服务器系统时区，前端浏览器用用户本地时区。同一段代码，在上海和纽约运行，getHours() 返回值可能差 15 小时。
关键判断点：
-
后端 API 返回的时间字符串带
Z（如"2024-05-01T12:00:00Z"）→ 是 UTC，用new Date(str)解析后所有 getter 方法返回的是本地等效时间 - 需要统一按 UTC 处理？用
getUTCHours()/getUTCDate()等系列方法 - 存数据库或传 API 前，明确用
toISOString()（强制转 UTC）或toUTCString()，别依赖toString()
真正麻烦的从来不是“怎么创建一个日期”，而是“怎么确保这个日期在东京用户点击、伦敦服务器解析、旧版 iOS Safari 渲染时，都代表同一个物理时刻”。时区、历法、API 设计三者咬合极紧，任何一处松动都会让时间变成幽灵值。
