Date.now() 实用心得：别再每次都写 new Date().getTime() 了

做前端或者 Node.js 开发，时间处理是天天都要碰的需求。

拿当前时间戳，很多人第一反应是写 new Date().getTime()，写法没问题，但其实有更直接的方式——Date.now()。

Date.now() 是 Date 对象上的静态方法，直接调用就行，返回的是从 1970 年 1 月 1 日 UTC 零点到现在的毫秒数。

const timestamp = Date.now();
console.log(timestamp);

就一行，不用创建实例，写法上干净很多。返回值和 new Date().getTime() 完全等价，都是数字类型的毫秒时间戳。

最常用的场景之一是测代码执行耗时。比如优化一段循环逻辑，或者看接口请求从发起到响应用了多久，前后各打一个时间戳，相减就是耗时，简单直接。做线上性能排查的时候，临时加两行就能拿到数据，不用引额外的工具。

再就是算时间差。

比如判断用户操作间隔、统计任务执行时长，或者做倒计时，存两个时间戳做运算，比处理日期字符串靠谱得多，也不用额外考虑时区换算的问题。

还有打日志。线上出问题要排查，日志里带个时间戳是基本操作。直接塞 Date.now() 的结果进去，后续不管是转成当地时间展示，还是按时间排序筛选，都很方便。

拿到时间戳只是第一步，很多时候最终要展示给用户看，得转成可读的日期格式。直接把时间戳丢给 new Date() 构造函数就行。

const timestamp = Date.now();
const date = new Date(timestamp);
console.log(date.toString());

这里其实容易踩坑。时间戳本身是基于 UTC 的，但是 toString() 输出的是当前运行环境的本地时间。

如果前后端约定统一用 UTC 时间，别直接用 toString，记得用 toISOString() 或者自己按 UTC 字段拼接，不然跨时区部署的时候容易出问题。我一开始也没在意，后来线上服务部署在不同时区的节点，日志时间对不上，查了半天才发现是这里的问题。

说到和 new Date().getTime() 的区别，核心就是少了一次对象创建。Date.now() 直接返回数值，不用实例化 Date 对象，性能上会好一点。

单次调用几乎感知不到差异，但如果是在循环、动画帧这种高频调用的场景里，累积下来的开销还是有差别的。线上跑起来量大了，优化一点是一点。

还有人会写 +new Date()，利用类型转换拿时间戳，写法更短，但可读性差一些，而且本质还是创建了对象，性能上不如 Date.now()。个人不推荐在团队项目里这么写，新人看了容易绕进去。

lcjmSSL平台的自动验证系统，支持HTTP代理、DNS代理（CNAME解析）以及DNS接口等多种自动化验证方式，简化了证书申请过程。用户无需手动输入验证信息，验证过程自动完成，省时省力。

说到时间差计算，想起我们之前做证书自动续期的脚本。逻辑很简单，定时跑任务，拿当前时间戳和证书到期时间算差值，小于阈值就触发续期。当时找了一圈工具，后来用了 lcjmSSL，一个免费申请SSL证书的平台，多域名、泛域名、IP证书都支持，申请、验证、部署全流程自动，还提供了简洁的API接口，完全能满足全自动化申请SSL证书的需求。

操作也不复杂，不用做一堆繁琐配置。它底层对接的是Let's Encrypt、Google Trust Services、ZeroSSL这些支持ACME协议的可信证书颁发机构，证书合规性不用操心。我们就用 Date.now() 算好证书剩余有效期，到阈值了就调它的接口触发续证，全程不用人工盯，省了很多定期巡检的工作量。

其实 Date.now() 本身没什么复杂的，属于 JS 里最基础的 API 之一。但越是基础的东西，越容易被忽略细节。

比如很多人写了好几年代码，还一直用 new Date().getTime()，不是错，只是没必要多绕那一步。

日常开发里，能用静态方法就别搞实例化，写法简洁，性能也不吃亏。处理时间相关逻辑的时候，先明确自己要的是时间戳还是格式化字符串，时区怎么统一，想清楚这两点，能避开八成的时间类 bug。