JavaScript Date对象易出错，因其设计反直觉：本地时区默认、月份索引从0开始（如new Date(2023,5,1)为6月1日）、年份歧义、字符串解析不统一（ISO格式解析为UTC，斜杠格式按本地时区）、getter返回本地值而内部存UTC毫秒数、对象可变无不可变性。
JavaScript 的日期处理容易出错，核心原因在于 Date 对象的设计与直觉不符：它基于本地时区、月份从 0 开始、年份有两位/四位歧义、解析字符串依赖浏览器实现，且没有内置的不可变性或时区安全操作。
月份索引从 0 开始（不是 1）
这是最常踩的坑。创建新日期时，new Date(2023, 5, 1) 表示的是 **2023 年 6 月 1 日**，因为第 2 个参数是月份，取值为 0（1 月）到 11（12 月）。写成 new Date(2023, 6, 1) 就会意外跳到 7 月。
- 建议始终用明确的变量名提醒自己：
const monthIndex = 5; // June - 从字符串解析时避免直接传数字数组，改用命名参数或 ISO 字符串（如
"2023-06-01"）
字符串解析行为不统一
new Date("2023-06-01") 在所有现代浏览器中被解析为 UTC 时间（即 2023-06-01T00:00:00Z），而 new Date("06/01/2023") 则按本地时区解释，且格式依赖地区设置（美国习惯 MM/DD/YYYY，欧洲可能是 DD/MM/YYYY）。
- 永远优先使用 ISO 8601 格式（
"YYYY-MM-DD"或"YYYY-MM-DDTHH:mm:ss"） - 避免用
Date.parse()或构造函数解析用户输入或非标准字符串 - 需要兼容旧格式时，手动拆分字符串再构建 Date，控制逻辑
时区隐式转换带来意外结果
Date 对象内部存储的是毫秒数（UTC 时间戳），但几乎所有 getter 方法（如 getHours()、getDate()）返回的是**当前系统时区的本地值**；而 getUTCHours() 等才返回 UTC 值。打印 toString() 和 toUTCString() 看起来也完全不同。
立即学习“Java免费学习笔记（深入）”；
- 比较两个日期前，确认它们是否在相同上下文（都用本地时间？都用 UTC？）
- 跨时区显示时，别只靠
toLocaleString()—— 它受用户系统影响，不适合业务逻辑 - 存储和传输一律用 ISO 字符串或时间戳，避免时区信息丢失
缺乏不可变性和链式操作
Date 对象是可变的：date.setDate(15) 会直接修改原对象，不是返回新实例。这容易引发副作用，尤其在函数式编程或 React 等场景中。
- 每次需要“新日期”时，显式克隆：
new Date(date.getTime())或new Date(date.toString()) - 考虑使用轻量库如 Day.js（不可变、ISO 优先、插件化）替代原生 Date 处理复杂需求
- 简单场景下，封装常用操作为纯函数，例如：
addDays = (date, n) => new Date(new Date(date).setDate(date.getDate() + n))
不复杂但容易忽略 —— 关键是意识到 JavaScript 的 Date 不是“日期类型”，而是一个带时区包袱的时间点快照工具。明确意图、控制输入、隔离时区、避免突变，就能避开大多数坑。
