关键在于毫秒是否被静默抹除或四舍五入：13位时间戳含毫秒，10位仅到秒；深拷贝后若 getTime() 值变化且差值为毫秒级，即发生精度丢失。

识别日期精度丢失，关键不是看时间“看起来对不对”，而是看毫秒部分是否被静默抹除或四舍五入——尤其在深拷贝后还原为 Date 对象或字符串时。

看原始时间戳是否含毫秒信息

检查原始数据源：如果时间字段是 13 位数字（如 1714589928123），它代表毫秒级时间戳；如果是 10 位（如 1714589928），则只到秒。前端常用 Date.now()、后端用 System.currentTimeMillis() 都默认生成 13 位。若原始值有毫秒但拷贝后变成整秒（比如 123 变成 000），就已发生截断。

比对深拷贝前后的时间值

不要只比对 toString() 或 toLocaleString() 结果，它们常隐藏毫秒。应直接比对毫秒数：

• 原始 Date 对象：original.getTime()
• 拷贝后 Date 对象：copied.getTime()
• 若两者不等，且差值是毫秒级（

警惕 JSON 序列化型深拷贝

JSON.stringify() + JSON.parse() 是常见“伪深拷贝”手段，但它会把 Date 对象转成 ISO 字符串（如 "2026-05-01T10:58:48.123Z"），再 parse 时——

• 若目标环境支持 ISO 字符串解析（现代浏览器/Node.js），毫秒通常保留
• 但某些旧版运行时或自定义解析逻辑可能只取到秒，丢弃 .123
• 更隐蔽的是：若原始 Date 来自 new Date('2026-05-01 10:58:48')（无毫秒），而你本意要保留毫秒，那问题出在源头，不是拷贝本身

验证数据库或接口返回的字段精度

如果时间来自后端，需确认传输格式：

• 返回的是 13 位数字？还是 ISO 字符串？字符串里是否包含小数秒（如 "2026-05-01T10:58:48.123Z"）？
• 若后端用 MySQL 存 TIMESTAMP 未声明精度（如 TIMESTAMP 而非 TIMESTAMP(3)），入库时毫秒已被截断或四舍五入，前端再怎么深拷贝也救不回
• Java 后端若用 LocalDateTime 接收毫秒时间戳，也会天然丢失时区和毫秒精度