JavaScript Date对象仅存储毫秒时间戳，不处理时区转换、加减或格式化；new Date('2023-10-05')因ISO字符串按UTC解析导致本地时区偏差；应使用new Date(2023,9,5)或Date.UTC()明确日历日；时间运算需统一基准，避免混用getHours()/getUTCHours()；复杂场景须依赖date-fns等专用库。
JavaScript 的 Date 对象本身不处理时区转换、加减运算或格式化——它只存储一个毫秒时间戳（自 1970-01-01T00:00:00Z 起），所有“处理时间”的行为都依赖开发者手动调用方法或借助外部逻辑。
为什么 new Date('2023-10-05') 可能不是你想要的日期？
ISO 格式字符串（如 '2023-10-05'）被解析为 UTC 时间，再转成本地时区显示。在东八区执行 new Date('2023-10-05') 实际得到的是 2023-10-04T16:00:00.000Z 对应的本地时间（即 10 月 5 日 00:00 UTC → 本地 10 月 5 日 08:00），但如果你本意是“今天这个日历日的凌晨”，结果就偏了。
- 想表示本地日历日：用
new Date(2023, 9, 5)（注意月份是 0–11） - 想表示 UTC 日历日：用
new Date(Date.UTC(2023, 9, 5)) - 避免字符串解析歧义：不要传
'2023-10-05'或'10/05/2023'给Date构造函数
getHours() / getUTCHours() 混用会导致时区错乱
同一个 Date 实例，getHours() 返回本地时区小时，getUTCHours() 返回 UTC 小时。混用二者做计算（比如“加 3 小时”）却不统一基准，结果会因用户所在时区而异。
- 做时间加减：统一用
getTime()获取毫秒数，加减后再构造新Date - 比较两个时间点是否同一天：用
toDateString()或提取年月日做数值比对，别比getHours() - 显示时间：明确你要展示的是本地时间还是服务端时间，再选
toLocaleTimeString()或toUTCString()
toISOString() 和 toJSON() 都返回 UTC 字符串，但语义不同
toISOString() 严格返回 ISO 8601 格式（'2023-10-05T08:30:00.000Z'），而 toJSON() 内部调用的就是 toISOString()，但它的存在意义是让 Date 在 JSON.stringify() 中自动序列化为字符串。
立即学习“Java免费学习笔记（深入）”；
- 需要可读性时间字符串：用
toLocaleString('zh-CN')，别依赖toString() - 需要与后端交换时间：优先用
toISOString()，确保双方都按 UTC 解析 - 别用
JSON.stringify(new Date())代替显式调用toISOString()，因为语义不清晰且无法控制精度
为什么 new Date().getTime() + 24 * 60 * 60 * 1000 不等于“明天此时”？
因为夏令时切换、闰秒、系统时钟调整都可能导致 24 小时 ≠ 一个日历日。例如某地夏令时开始当日，本地时间从 02:00 直接跳到 03:00，那么“今天 02:00 + 24 小时”实际落在次日 03:00，而非 02:00。
- 要获取“明天同一日历时间”：用
setDate(getDate() + 1) - 要获取“7 天后同一时刻”：用
setTime(getTime() + 7 * 24 * 60 * 60 * 1000)（仅适用于不跨 DST 边界的小跨度） - 复杂场景（如定时任务、日程提醒）：必须用专门库（如 date-fns、luxon）处理日历算术
原生 Date 的最大陷阱，是它看起来能“处理时间”，其实只是个带时区标签的毫秒计数器——真正的时间语义（今天、下周三、上个月最后一天）全靠你定义和维护。
