`new Date().getXXX()` 获取当前时间为何返回 NaN 或意外值？

Question

常见问题：`new Date().getHours()` 等方法返回 `NaN`？ 根本原因并非 `getXXX()` 本身出错，而是 `new Date()` 构造失败，返回了 **Invalid Date** 对象（其内部时间值为 `NaN`）。此时调用 `getHours()`、`getFullYear()` 等访问器方法，虽不报错，但会静默返回 `NaN`（规范要求：对无效日期调用 getter 均返回 `NaN`）。典型诱因包括：传入非法字符串（如 `'2024-13-01'`、`'2024/02/30'`、含多余空格或非标准格式的 `'2024-01-01T12:30:xx'`），或传入 `undefined`/`null`/空字符串等假值。需注意：`console.log(new Date('invalid'))` 显示 `"Invalid Date"`，但 `isNaN(new Date('invalid').getTime())` 才是可靠检测方式。建议始终校验 `date instanceof Date && !isNaN(date.getTime())` 再调用 `getXXX()` 方法，避免隐蔽逻辑错误。

Answer 1

```html

一、现象层：为什么 new Date().getHours() 会返回 NaN？

开发者常在控制台执行 new Date('2024-13-01').getHours()，却意外得到 NaN，误以为是 getHours() 方法异常。实则该方法本身完全合规——它只是忠实地反射了底层时间值的无效性。JavaScript 规范（ECMA-262 §20.4.4）明确要求：对 Invalid Date 对象调用任何 getXXX() 访问器（如 getFullYear()、getMinutes()、getDate()），必须返回 NaN，且不抛出错误。

二、机制层：Date 构造函数的隐式失败与内部表示

• new Date(str) 依赖宿主环境的解析策略（V8/SpiderMonkey/JSC 实现略有差异），但均遵循 ISO 8601 子集；超出范围（如月份 13、2 月 30 日）、格式错位（'2024-01-01T12:30:xx'）、非法字符（中文破折号、全角空格）均导致构造失败。
• 失败后返回的仍是 Date 实例（instanceof Date === true），但其内部 [[DateValue]] slot 被设为 NaN（参见规范 §20.4.3.2）。
• console.log(new Date('invalid')) 输出 "Invalid Date" 是调试友好提示，非标准可编程接口；真正可靠的检测仅能通过 isNaN(date.getTime()) 或 date.toString() === 'Invalid Date'（后者有兼容性风险）。

三、诊断层：系统化排查路径

检查项	推荐方式	反例说明
类型安全	date instanceof Date	new Date(null) → Date 实例，但无效
值有效性	!isNaN(date.getTime())（黄金标准）	isFinite(date.getTime()) 不足（+∞/-∞ 也满足）
字符串输入溯源	date.toISOString() 抛错？或 date.valueOf() === NaN	new Date(' 2024-01-01 ') 在部分环境被宽容解析，部分失败

四、解决方案层：防御性编程实践

function safeGetHours(dateInput) {
  const date = new Date(dateInput);
  // ✅ 双重校验：类型 + 值有效性
  if (!(date instanceof Date) || isNaN(date.getTime())) {
    throw new TypeError(`Invalid date input: ${String(dateInput)}`);
  }
  return date.getHours();
}

// 更健壮的工厂函数（支持多种输入归一化）
function parseDate(input) {
  if (input == null) return null;
  const d = new Date(input);
  return (d instanceof Date && !isNaN(d.getTime())) ? d : null;
}

五、进阶层：跨浏览器与国际化陷阱

Chrome/Firefox/Safari 对非标准格式（如 '01/32/2024'、'2024年1月1日'）解析行为不一致；Node.js v18+ 启用 --icu-data-dir 后可能增强本地化解析，但也引入新歧义。强烈建议：所有外部输入（API、表单、URL 参数）必须先经正则/库（如 Luxon 的 DateTime.fromISO()）预校验，再交由 Date 构造。避免依赖浏览器“尽力而为”的解析逻辑。

六、架构层：前端日期处理的演进范式

graph TD
  A[原始输入] --> B{是否已标准化？}
  B -->|否| C[使用 date-fns/parseISO 或正则清洗]
  B -->|是| D[构造 Date 实例]
  C --> D
  D --> E[执行 isValidDate 检查]
  E -->|失败| F[上报监控 + 返回默认值/空状态]
  E -->|成功| G[调用 getXXX 方法]

```