现代场景下JS new Date().getTime()字符串长度确定性与Unix时间戳问题

1. 10位和13位时间戳的差异 #

标准Unix时间戳是秒级精度，从1970年1月1日0点开始计算的秒数，目前确实是10位。而JS、Java的getTime()方法返回的是毫秒级精度的时间戳，比秒级多了3位毫秒数值，所以当前是13位长度。

2. getTime()返回14位的时间节点 #

你测试得出的2281-2286年左右的时间节点是准确的：13位毫秒级时间戳的最大值为9999999999999，换算成公历时间就是2286年前后，距离现在还有超过250年的跨度，几乎所有当代业务的生命周期都不会覆盖到这个时间点。

3. 取ID前13位作为时间戳的可靠性 #

这个方案在可预见的未来是完全可靠的：

• 只要时间戳还处于13位区间，拼接ID的前13位必然是生成时的毫秒时间戳，不受后面随机数长度的影响
• 哪怕后续需要兼容更久的时间，也可以通过判断时间戳长度的方式做兼容调整，不需要推翻现有逻辑

4. 现有ID生成逻辑的优化建议 #

你的当前实现存在小概率的重复风险：同一毫秒内生成ID时，随机数有概率碰撞。如果需要更高的唯一性或者方便后续字段截取，可以把随机数部分固定为6位，修改后的代码如下：

function generateUniqueID() {
    return `${new Date().getTime()}${Math.round(Math.random() * Math.pow(10,6)).toString().padStart(6, '0')}`;
}

修改后随机数固定为6位，你也可以选择直接截取后6位分离随机数和时间戳，不需要依赖时间戳长度判断。

内容的提问来源于stack exchange，提问作者gene b.