获取当前时间戳最推荐的方式是使用 date.now()。1. 使用 date.now() 可直接获取毫秒级时间戳，如 const timestampms = date.now(); 2. 若需秒级时间戳，可将毫秒级时间戳除以1000并向下取整，如 const timestampsec = math.floor(date.now() / 1000); 3. 其他方法包括 new date().gettime()、new date().valueof() 和 +new date()，但 date.now() 更清晰高效；时间戳常用于唯一标识、缓存失效、性能测量、数据排序、会话管理等场景；毫秒级精度更高，适用于高精度需求，秒级常用于后端交互，需根据对接系统要求选择；使用时需注意时区问题（时间戳为utc，显示时按本地时区转换）、客户端时钟偏差、闰秒忽略及旧浏览器兼容性问题，其中 date.now() 在现代环境中兼容性良好，但在极老浏览器中需降级使用 new date().gettime()。
在JavaScript中，获取当前时间戳最直接、最推荐的方式是使用
Date.now()。它返回自1970年1月1日00:00:00 UTC（Unix纪元）以来经过的毫秒数。
解决方案
要获取当前时间戳，最简洁高效的办法就是利用
Date.now()这个静态方法。它直接返回一个表示当前时间的数字，单位是毫秒。
const timestampMs = Date.now(); // 获取毫秒级时间戳 console.log(timestampMs); // 例如: 1678886400000
如果你需要的是秒级时间戳，这在很多后端接口或数据库设计中更常见，只需要将毫秒级时间戳除以1000并向下取整即可：
const timestampSec = Math.floor(Date.now() / 1000); // 获取秒级时间戳 console.log(timestampSec); // 例如: 1678886400
除了
Date.now()，你也可以通过创建
Date对象实例来获取时间戳，虽然它不如
Date.now()直接：
const now = new Date(); const timestampMsViaGetTime = now.getTime(); // 获取毫秒级时间戳 const timestampMsViaValueOf = now.valueOf(); // 效果同getTime() console.log(timestampMsViaGetTime); console.log(timestampMsViaValueOf);
甚至还有一种更“黑魔法”的写法，利用
Date对象在数字上下文中的隐式转换：
const timestampMsViaUnaryPlus = +new Date(); // 同样获取毫秒级时间戳 console.log(timestampMsViaUnaryPlus);
不过，我个人更倾向于使用
Date.now()，因为它意图明确，代码可读性也更好，而且性能上通常是最佳的。
为什么我们需要时间戳？它在实际开发中有哪些常见用途？
时间戳，说白了就是一个数字，代表了从某个固定时间点（通常是Unix纪元）到现在经过了多少时间。它之所以如此重要，在于其简洁性和唯一性。
我常常用时间戳来处理各种场景：
-
唯一标识和命名： 我会用时间戳来命名上传的文件，比如
image_1678886400000.jpg
。这样既保证了文件名的唯一性，又能一眼看出文件大概的创建时间，比什么随机字符串好记多了。在数据库中，时间戳也常被用作记录的创建或更新时间，方便排序和追溯。 -
缓存失效： 在前端开发中，为了避免浏览器缓存旧的JS或CSS文件，我们经常在文件名后面加上版本号或时间戳，例如
bundle.js?v=1678886400000
。这样每次部署新版本，即使文件名没变，URL变了，浏览器也会重新下载最新文件。 - 性能测量： 想知道某个函数执行了多久？在函数开始和结束时分别获取时间戳，然后相减，就能得到精确的执行时间。这在性能优化时非常有用。
- 数据排序和筛选： 在社交媒体应用中，时间戳是排序动态、评论的天然依据。它能确保内容按时间顺序展示，并且可以根据时间范围进行筛选。
- 会话管理和令牌过期： 在用户登录或API认证中，我们可以为会话或JWT令牌设置一个过期时间戳。当当前时间超过这个时间戳时，就认为会话或令牌失效，需要重新认证。
时间戳的本质是纯粹的数字，这让它在跨系统、跨语言之间进行时间传递和比较时变得异常方便，因为它不涉及复杂的日期格式解析和时区转换问题。
毫秒级和秒级时间戳，我该如何选择？它们有什么区别？
在JavaScript中，
Date.now()返回的是毫秒级时间戳，而很多其他系统（比如Unix/Linux命令行工具、一些数据库）更常用秒级时间戳。选择哪个，主要看你的具体需求和与哪个系统对接。
区别：
-
精度： 毫秒级时间戳（如
1678886400000
）比秒级时间戳（如1678886400
）精度更高。毫秒级能精确到千分之一秒，而秒级只能精确到秒。 - 数值大小： 毫秒级时间戳通常是一个13位或14位的数字，而秒级时间戳通常是10位或11位的数字。
如何选择：
- 需要高精度时，选择毫秒级： 如果你在做性能测试，需要精确到毫秒来测量代码执行时间；或者在处理快速连续发生的事件，需要区分它们发生的微小时间差时，毫秒级是首选。例如，我写一些动画或游戏逻辑时，计算帧率就离不开毫秒级的时间差。
-
与后端/数据库对接时，根据对方要求： 很多后端API或者数据库习惯用秒级时间戳来存储和传递时间信息。如果你前端需要向后端发送时间数据，或者从后端接收时间数据，就得和后端保持一致。我踩过坑，后端说我传的格式不对，结果发现是精度问题，他们只要秒级的，我传了毫秒级的，导致数据解析失败。这种情况下，你可能需要将
Date.now()
获取到的毫秒级时间戳除以1000并取整。 - 存储空间或可读性考虑时，选择秒级： 虽然现在存储成本很低，但秒级时间戳的数字更短，在某些特定场景下可能会略微节省存储空间。同时，对于人眼来说，10位的秒级时间戳也比13位的毫秒级看起来更“清爽”一些。
总的来说，JavaScript默认提供毫秒级，如果你没有特殊要求，或者需要最高精度，就直接用毫秒级。如果需要与外部系统交互，务必确认对方需要哪种精度，并进行相应的转换。
获取时间戳时可能遇到的陷阱和跨平台兼容性问题？
获取时间戳本身在现代JavaScript环境中是相当稳定的，
Date.now()已经是ECMAScript 5标准的一部分，几乎所有现代浏览器和Node.js环境都完美支持。然而，在使用时间戳时，尤其是涉及到时间显示和比较时，还是有一些需要注意的“坑”。
-
时区陷阱（时间戳本身是UTC，但转换为日期时要注意时区）： 最让我头疼的不是时间戳本身，而是用它来构造日期字符串时，时区带来的混乱。时间戳（Unix时间戳）的定义是“自1970年1月1日00:00:00 UTC以来的毫秒数”，它本身是一个与时区无关的纯数字。但当你用这个时间戳去创建一个
Date
对象，并调用toLocaleString()
、getHours()
等方法时，这些方法默认会根据运行环境的本地时区来解释这个时间戳。比如，你存了一个时间戳
1678886400000
，它对应的是 UTC 时间 2023年3月15日 00:00:00。如果你在东八区（北京时间）的机器上用new Date(1678886400000)
，它会显示为 2023年3月15日 08:00:00。但在UTC时区的机器上，它仍然是 2023年3月15日 00:00:00。所以，处理时间戳的时候，脑子里一定要绷着“UTC”这根弦，如果需要展示给用户，明确告知用户时区，或者统一转换为UTC时间再展示。 客户端系统时钟偏差： JavaScript的
Date.now()
获取的是客户端（用户设备）的系统时间。如果用户的电脑时间不准确（比如慢了或快了），那么你获取到的时间戳也会是错误的。这在需要严格时间同步的场景下是个大问题，比如在线考试、金融交易等。对于这类场景，通常需要从服务器获取一个权威的时间戳，而不是完全依赖客户端时间。闰秒（Leap Seconds）： 闰秒是为了让UTC时间与地球自转周期保持一致而偶尔插入或删除的一秒。幸运的是，JavaScript的
Date
对象实现（以及大多数编程语言的日期库）通常不直接处理闰秒。它们认为每一分钟都有60秒，时间是连续流逝的。这意味着时间戳的计算不会因为闰秒而出现中断或跳跃。所以，对于日常开发来说，你通常不需要担心闰秒会影响Date.now()
的准确性。旧浏览器兼容性： 虽然现在很少见了，但在非常老的IE浏览器（IE8及以下）中，
Date.now()
是不支持的。在这种情况下，你可能需要使用new Date().getTime()
作为替代方案，因为它兼容性更好。不过，随着现代浏览器普及，这已经不是一个普遍的问题了。
总而言之，获取时间戳本身很简单，但如何正确地使用和解释这个时间戳，尤其是涉及到时区和多端同步时，才是真正考验开发者功力的地方。
