JavaScript Date对象月份从0开始导致getMonth()返回值比实际小1，需+1修正；安全格式化推荐Intl.DateTimeFormat或手动补零；日期计算应避免直接增减月/日，而用new Date(y,m±1,d)或setDate等方法处理边界。
JavaScript 原生 Date 对象本身不提供安全的格式化方法，也不直接支持跨时区日期计算；盲目调用 getMonth() 或拼接字符串极易出错。
为什么 getMonth() 返回的月份总是比预期小 1？
这是最常踩的坑：JavaScript 的 Date 月份是基于 0 的索引（0 表示一月，11 表示十二月），但年、日、小时等其他字段都是从 1 或 0 正常计数。这种不一致性导致大量逻辑错误。
- 写
new Date(2024, 5, 1)创建的是 2024 年 6 月 1 日，不是 5 月 -
date.getMonth() + 1才是真实月份，漏加会导致显示为 “2024-00-01” 这类非法格式 - 使用
toLocaleDateString()时也要注意 locale 和 options 配置，否则在 Safari 和 Chrome 中输出格式可能不同
如何安全地格式化日期为 “YYYY-MM-DD HH:mm:ss”？
避免手撕字符串拼接，优先用 Intl.DateTimeFormat 或补零工具函数。原生 toISOString() 只返回 UTC 时间，不能直接用于本地时间展示。
- 本地时间格式化推荐：
new Intl.DateTimeFormat('zh-CN', { year: 'numeric', month: '2-digit', day: '2-digit', hour: '2-digit', minute: '2-digit', second: '2-digit', hour12: false }).format(date) - 若需固定格式且兼容老环境，手动补零更可控：
`${date.getFullYear()}-${String(date.getMonth() + 1).padStart(2, '0')}-${String(date.getDate()).padStart(2, '0')} ${String(date.getHours()).padStart(2, '0')}:${String(date.getMinutes()).padStart(2, '0')}:${String(date.getSeconds()).padStart(2, '0')}` - 别用
date.toString().slice(0, 24)这类“取巧”方式——不同引擎输出长度和顺序不一致
怎样正确计算“7 天后”或“上个月第一天”？
直接对 getDate() 或 getMonth() 加减数字看似简单，但在月末、闰年、跨年等边界场景会失效。例如：1 月 31 日加 1 个月 ≠ 2 月 31 日（根本不存在）。
立即学习“Java免费学习笔记（深入）”；
- 加减天数较安全：
const nextWeek = new Date(date); nextWeek.setDate(date.getDate() + 7); - 加减月份必须重新构造：
const nextMonth = new Date(date.getFullYear(), date.getMonth() + 1, 1);（先设为下月 1 日，再调整日期） - 获取上个月最后一天：
new Date(date.getFullYear(), date.getMonth(), 0)（利用“第 0 天”自动回退到上月末） - 涉及时区偏移的计算（如“北京时间上午 9 点”）应显式使用
setUTCHours()或借助toLocaleString('zh-CN', { timeZone: 'Asia/Shanghai' })
真正难的不是写对一行代码，而是意识到 JavaScript 的 Date 是一个没有不可变性、没有时区透明性、也没有范围校验的脆弱对象——所有“看起来能跑”的格式化或计算，都可能在某个特定日期或浏览器中突然崩掉。
