Date对象本质是带时区的时间戳快照，所有方法操作毫秒数；new Date('2023-10-01')因UTC解析致本地显示偏差，需用'2023-10-01T00:00:00'或new Date(2023,9,1)避免歧义。
JavaScript 的 Date 对象不是“操作日期的工具箱”，而是带时区的**时间戳快照**——所有方法本质都是对毫秒数的读写，理解这点才能避开多数坑。
为什么 new Date('2023-10-01') 在某些浏览器返回前一天？
因为 '2023-10-01' 被解析为 UTC 时间，再转成本地时区显示。中国用户看到 Sun Oct 01 2023 08:00:00 GMT+0800 是正常的，但如果你期望它代表“本地 10 月 1 日零点”，就得显式补全时间部分：
-
new Date('2023-10-01T00:00:00')—— 强制按本地时区解析（ISO 格式带 T） -
new Date(2023, 9, 1)—— 构造函数参数中月份是 0 起始，9才是十月 - 避免用
new Date('2023/10/01')：斜杠格式在 Safari 中可能被当作本地时间，Chrome 当 UTC，行为不一致
getMonth()、getDate() 和 getUTCDate() 到底该用哪个？
取决于你要表达的语义：
-
getDate()返回本地时区“今天几号”，比如 UTC 时间是 9 月 30 日 18:00，中国用户调用会得1（10 月 1 日） -
getUTCDate()返回 UTC 时间的“几号”，同一时刻永远返回30 -
getMonth()永远返回 0–11，别直接当月份用；显示时记得+1 - 跨时区计算（如“用户所在地区本月第几天”）必须用
getDate()系列；做服务器时间比对或日志归档用getUTCxxx()系列
setDate() 修改日期后，为什么小时变了？
因为 setDate() 只改“日”，其他字段（时分秒毫秒）保持不变。如果原时间是 new Date('2023-01-31T15:00:00')，执行 date.setDate(32) 后变成 2 月 1 日 15:00:00 —— 看似合理，但如果原时间是 2023-01-31T23:00:00，加一天会进到 2 月 1 日 23:00:00，但若你本意是“加 24 小时”，更安全的做法是：
立即学习“Java免费学习笔记（深入）”；
-
date.setTime(date.getTime() + 24 * 60 * 60 * 1000)—— 显式加毫秒，不依赖日历逻辑 - 用
date.setDate(date.getDate() + 1)前先确认是否需要保留原始时分秒；否则建议用date.setHours(0, 0, 0, 0)归零再操作 - 注意：
setMonth()会自动处理天数溢出（比如 1 月 31 日设成 2 月 → 变成 3 月 3 日），这是隐式行为，容易误判
toJSON()、toISOString() 和 toString() 输出差异在哪？
三者都返回字符串，但语义和用途完全不同：
-
date.toJSON()等价于date.toISOString()，输出"2023-10-01T00:00:00.000Z"，用于 API 通信或 JSON 序列化 -
date.toString()返回本地时区可读字符串，如"Sun Oct 01 2023 08:00:00 GMT+0800 (China Standard Time)"，适合调试打印 -
date.toLocaleString()会根据系统语言和地区格式化，但结果不可控，不适合存储或传输 - 警惕：
JSON.stringify(new Date())内部会调用toJSON()，所以序列化后是 ISO 字符串，不是 Date 对象
最常被忽略的是：所有 Date 方法都受本地时区影响，没有“绝对日期”这种东西；传给后端的时间，要么统一用 UTC 字符串（toISOString()），要么明确约定时区偏移（date.getTimezoneOffset() 返回分钟数，注意是反向的）。
