关键在于毫秒是否被静默抹除或四舍五入：13位时间戳含毫秒，10位仅到秒；深拷贝后若 getTime() 值变化且差值为毫秒级，即发生精度丢失。
识别日期精度丢失，关键不是看时间“看起来对不对”，而是看毫秒部分是否被静默抹除或四舍五入——尤其在深拷贝后还原为 Date 对象或字符串时。
看原始时间戳是否含毫秒信息
检查原始数据源：如果时间字段是
13 位数字
（如
），它代表毫秒级时间戳；如果是 10 位（如
），则只到秒。前端常用
、后端用
都默认生成 13 位。若原始值有毫秒但拷贝后变成整秒（比如
变成
），就已发生截断。
比对深拷贝前后的时间值
不要只比对
或
结果，它们常隐藏毫秒。应直接比对毫秒数：
原始 Date 对象：
拷贝后 Date 对象：
若两者不等，且差值是毫秒级（
警惕 JSON 序列化型深拷贝
是常见“伪深拷贝”手段，但它会把 Date 对象转成 ISO 字符串（如
），再 parse 时——
若目标环境支持 ISO 字符串解析（现代浏览器/Node.js），毫秒通常保留
但某些旧版运行时或自定义解析逻辑可能只取到秒，丢弃
更隐蔽的是：若原始 Date 来自
（无毫秒），而你本意要保留毫秒，那问题出在源头，不是拷贝本身
验证数据库或接口返回的字段精度
如果时间来自后端，需确认传输格式：
返回的是 13 位数字？还是 ISO 字符串？字符串里是否包含小数秒（如
）？
若后端用 MySQL 存
未声明精度（如
而非
），入库时毫秒已被截断或四舍五入，前端再怎么深拷贝也救不回
Java 后端若用
接收毫秒时间戳，也会天然丢失时区和毫秒精度
17145899281231714589928Date.now()System.currentTimeMillis()123000toString()toLocaleString()original.getTime()copied.getTime()JSON.stringify() + JSON.parse()"2026-05-01T10:58:48.123Z".123new Date('2026-05-01 10:58:48')"2026-05-01T10:58:48.123Z"TIMESTAMPTIMESTAMPTIMESTAMP(3)LocalDateTime