最稳妥创建Date对象用数字参数或时间戳：new Date(2024,4,20)注意月从0始，new Date(1716192000000)最可靠；获取时间用getFullYear()、getDate()等本地方法；格式化推荐toLocaleDateString('zh-CN',{year:'numeric',month:'2-digit',day:'2-digit'})或toISOString()。
如何创建和初始化 Date 对象
直接调用 Date() 构造函数是最常见的起点，但行为差异很大：不带参数时返回当前时间；带字符串参数时依赖浏览器解析（不推荐）；最稳妥的是用数字参数或时间戳。
-
new Date()→ 当前本地时间 -
new Date('2024-05-20')→ 可能被解析为 UTC 时间（尤其 ISO 格式），在 Safari 和旧版 Chrome 中行为不一致 -
new Date(2024, 4, 20)→ 注意：月份从 0 开始，4表示五月，这是最容易出错的地方 -
new Date(1716192000000)→ 毫秒级时间戳（自 1970-01-01 UTC 起），最可靠、无歧义
获取年月日时分秒该用哪些方法
区分「本地时间」和「UTC 时间」是关键。日常显示基本都用本地方法；做跨时区计算或服务端对齐才考虑 UTC 方法。
- 年：
getFullYear()（推荐），不是getYear()（已废弃，返回距 1900 的偏移） - 月：
getMonth()返回 0–11，显示前务必 +1 - 日：
getDate()是当月第几天（1–31），别和getDay()混淆（后者返回星期几，0=周日） - 时分秒：
getHours()/getMinutes()/getSeconds()全部返回本地时间值 - 毫秒：
getMilliseconds()，不是getTime()（后者返回完整时间戳）
格式化输出时为什么 toLocaleDateString 总出问题
toLocaleDateString() 和 toLocaleTimeString() 看似方便，但默认行为受用户系统语言和地区设置影响，同一段代码在中文 Windows 和英文 macOS 上可能输出不同格式。
const d = new Date(2024, 4, 20, 14, 30); console.log(d.toLocaleDateString()); // 可能输出 '2024/5/20' 或 '20/05/2024' 或 '5/20/2024' console.log(d.toLocaleTimeString()); // 可能含 AM/PM，也可能用 24 小时制
若需稳定格式，显式传入 locales 和 options：
立即学习“Java免费学习笔记（深入）”；
const opts = { year: 'numeric', month: '2-digit', day: '2-digit' };
console.log(d.toLocaleDateString('zh-CN', opts)); // '2024-05-20'
更彻底的控制建议用 toISOString()（固定 ISO 8601 格式，UTC 时区）再自行截取，或引入轻量库如 date-fns 的 format()。
修改日期（加减天数、月份）为什么不能直接改 getXXX 方法的返回值
getXXX() 系列全是只读访问器，修改它们的返回值毫无作用。真正改变日期要用 setXXX() 方法，且注意副作用——比如 setMonth(1) 在 1 月 31 日上调用，会溢出到 3 月 3 日（因为二月没有 31 日）。
- 加 7 天：
d.setDate(d.getDate() + 7) - 加 1 个月：
d.setMonth(d.getMonth() + 1)，但要小心月末边界（如 1 月 31 日 → 3 月 3 日） - 重置时间部分为 00:00:00.000：
d.setHours(0, 0, 0, 0) - 避免手动计算：跨月/年运算强烈建议用
date-fns的addDays()、addMonths()，内部处理了所有边界情况
时间计算里最隐蔽的坑是时区切换——比如在夏令时开始当天调用 setDate()，可能跳过一小时或重复一小时，导致结果偏差。业务中涉及精确计时（如倒计时、预约提醒），优先用时间戳差值计算，而非反复 set/get。
