JS获取当前时间戳：Date.now()与new Date().getTime()的区别

一、语法形态与返回值本质

在 JavaScript 开发中，时间戳通常指 UNIX 时间戳（Unix Epoch Time），即协调世界时（UTC）1970 年 1 月 1 日 00:00:00 距今流逝的时间总量。在浏览器与 Node.js 运行时中，二者默认均以毫秒（milliseconds）为单位，表现为一个 13 位的正整数。

1. Date.now() 的调用方式

Date.now() 是内置对象 Date 本身挂载的静态方法（Static Method）。调用时不需要使用 new 关键字，直接通过构造函数名称点号调用即可：

// 获取当前时间的毫秒时间戳（静态方法调用）
const currentTimestamp = Date.now();
console.log(currentTimestamp);
console.log(typeof currentTimestamp);

2. new Date().getTime() 的调用方式

new Date().getTime() 采用面向对象常见的实例化操作。首先通过 new Date() 在内存中创建一个表示当前时间点的 Date 对象实例，随后调用该实例在原型链（Date.prototype）上定义的成员方法 getTime()：

// 获取当前时间的毫秒时间戳（实例化后调用实例方法）
const dateInstance = new Date();
const currentTimestamp = dateInstance.getTime();
console.log(currentTimestamp);
console.log(typeof currentTimestamp);

二、底层执行与内存分配模型

虽然两者输出的数值一致，但 JavaScript 引擎（以 Google Chrome 和 Node.js 底层的 V8 引擎为例）在底层所经历的执行链路截然不同。理解这一底层差异，是掌握二者选型依据的核心关键。

1. Date.now() 的执行路径：零堆分配直通

当执行 Date.now() 时，JavaScript 引擎将其识别为内部 Built-in 静态函数。在 V8 引擎中，该调用会被快速导向系统级的时钟接口（例如 Linux/macOS 下的 gettimeofday 或 clock_gettime，底层封装为 OS::TimeCurrentMillis()）。

系统内核将当前时间以 64 位浮点数格式计算完毕后，引擎直接封装为 JavaScript 原始类型 Number 压入执行栈中返回。整个过程完全在执行栈与操作系统内核之间完成交互，在 JavaScript 堆内存（Heap）中分配的临时对象数量严格为 0。

2. new Date().getTime() 的执行路径：堆对象分配与垃圾回收

相比之下，new Date().getTime() 经历了一条复杂的对象生命周期链路：

1. 堆内存分配：V8 引擎在内存堆中为新创建的 Date 实例开辟存储空间；
2. 内部槽位初始化：将实例的原型内部指针指向 Date.prototype，并将其内部槽位 [[DateValue]] 设为系统当前毫秒数；
3. 原型链查找：沿原型链查找 getTime 方法并入栈执行，读取 [[DateValue]] 槽中存储的数值；
4. 失活与垃圾回收：语句执行完毕后，该临时 Date 实例脱离当前上下文作用域，变为无法访问的垃圾对象，进入 V8 新生代垃圾回收器（Scavenger）的监控队列，等待随后的 GC 回收。

在单次或低频执行时，现代 JavaScript 引擎的高速优化使得该对象分配几乎不易察觉；但在高并发网络服务、高频动画循环或百万级数据清洗场景下，持续创建大量的无用临时 Date 实例会加剧堆内存碎片化，甚至频繁诱发垃圾回收器停顿（Stop-The-World）。

三、性能基准与行为验证：4 步测试法

为了验证理论上的内存与耗时差异，可以通过规范的基准测试步骤，在实际运行环境中进行比对。

步骤 1：准备干净的独立执行环境

推荐打开操作系统的终端，启动独立的 Node.js 进程，或者打开 Chrome 浏览器的无痕窗口（避免浏览器扩展程序的后台脚本占用主线程与干扰堆内存）。

步骤 2：编写大样本循环测试脚本

构建包含 1,000,000 次调用的对比脚本。为了防止 JavaScript 引擎 JIT 优化时的冷启动差异，我们先进行预热，再分别使用 console.time 与 console.timeEnd 记录实际执行耗时：

// benchmark.js
// 步骤一：预热 JIT 编译器
for (let i = 0; i < 10000; i++) {
  Date.now();
  new Date().getTime();
}

const ITERATIONS = 1000000;

// 步骤二：测试 Date.now() 静态方法
console.time('测试组-Date.now()');
for (let i = 0; i < ITERATIONS; i++) {
  Date.now();
}
console.timeEnd('测试组-Date.now()');

// 步骤三：测试 new Date().getTime() 实例化方法
console.time('测试组-new Date().getTime()');
for (let i = 0; i < ITERATIONS; i++) {
  new Date().getTime();
}
console.timeEnd('测试组-new Date().getTime()');

步骤 3：采集耗时指标与内存增长

在终端中运行上述脚本，观察执行完成后的时间输出。同时可以通过 Node.js 内置的 process.memoryUsage().heapUsed 打印循环前后的堆内存用量。

步骤 4：比对分析与验证结论

测试结果表明：在百万级的高频循环下，Date.now() 的执行速度通常是 new Date().getTime() 的 2 到 5 倍左右。由于 Date.now() 不产生堆对象分配，内存曲线呈现平稳直线；而 new Date().getTime() 会带来明显的内存阶梯式波动，并在循环结束后触发垃圾回收。

四、核心差异全景对照表

为了让两者的区别更加清晰直观，下表从语法、机制、适用性及历史兼容等多维度进行了综合对比：

if (!Date.now) {
  Date.now = function now() {
    return new Date().getTime();
  };
}

五、常见变体与混淆场景解析

1. +new Date() 语法糖的本质

许多开发者为了简写代码，习惯使用一元加号操作符 +new Date()。一元加号会强制触发对象的类型转换（调用 Date.prototype.valueOf()），将其转为原始数字。

虽然 +new Date() 的代码字符较少，但其底层依然完整执行了 new Date() 的对象实例化流程。因此，在内存开销和 GC 影响上，它与 new Date().getTime() 完全一致，并没有 Date.now() 零堆分配的优势。

2. 获取指定日期时间戳的场景限制

Date.now() 无法接收任何参数。当业务需要解析特定历史时刻或未来日期的毫秒数时（例如解析 "2026-10-30"），不能使用 Date.now()，必须借助 new Date(targetDate).getTime() 或 Date.parse(targetDate)：

// 正确做法：获取指定日期的时间戳
const specifiedTimestamp = new Date('2026-10-30T00:00:00Z').getTime();

// 错误做法：Date.now() 无法解析传入参数（参数会被直接忽略）
const wrongCall = Date.now('2026-10-30'); // 返回的仍然是执行当下的系统时间戳！

3. 需要微秒级高精度计时时的选择

无论 Date.now() 还是 new Date().getTime()，最小时间粒度都是毫秒（1ms），且都直接读取宿主操作系统的时钟。当需要进行高精度代码测速、物理渲染或计算动画帧差时，应改用 performance.now()：

• 微秒级亚毫秒精度：performance.now() 返回浮点数，小数部分可精确到微秒（千分之一毫秒）；
• 单调递增时钟（Monotonic Clock）：基于页面或进程启动的时间点单调累加，不受系统时间被手动调慢或 NTP 时钟回拨的影响。

六、业务选型决策指南

根据开发目标、运行环境以及精度要求，可以通过下述决策图快速确定最合适的时间戳获取方式：

归纳而言，在现代前端与 Node.js 研发实践中，遵循一条清晰的原则即可：

• 凡是获取“当前此刻”的毫秒时间戳：一律直接编写 Date.now()，享受最简练的语义、最快的执行速度与零垃圾回收负担；
• 凡是涉及“特定指定日期”的时间戳转换：使用 new Date(dateString).getTime() 或 Date.parse()；
• 凡是涉及“基准耗时测试与帧率渲染”：优先使用 performance.now() 避免时钟突变风险。