Java Instant.toEpochMilli()与JS Date.now()不同步致网络延迟计算为负如何解决

你的推测完全正确，跨设备时钟不同步是导致时延计算结果为负的核心原因，这是分布式端到端时延测量的经典问题，和代码逻辑无关。
两个时间API的本质都是读取设备本地的墙上时钟（wall-clock time）：

• 服务端Instant.toEpochMilli()读取的是服务端宿主机的系统时间，可被NTP校准、管理员手动调整，存在跳变可能
• 客户端Date.now()读取的是用户终端设备的系统时间，同样受NTP同步、手动改时、系统自动校时影响，不存在全局一致性
  当客户端本地时钟比服务端时钟慢30ms以上时，哪怕消息从服务端到客户端的传输耗时为0，计算出来的receivedAtTime - sentAtTime也会得到-30ms左右的负数。
  很多开发者会默认同内网环境下设备时钟天然对齐，实际上企业内网如果没有强制推送统一时间同步配置，员工终端、甚至运维不规范的服务器节点出现几十到上百毫秒的时钟偏移非常普遍，你观测到的-30ms属于偏移量很小的情况。
  除了固定的时钟偏移，NTP校准时的时钟回拨也可能触发偶发的负数值：如果服务端或客户端本地时钟之前跑快了，NTP同步时会直接把时钟往回调整，刚好打时间戳的时刻撞上回拨窗口，就会算出负数。

根据你的场景（内网部署、250ms有效期的流式报价），可以按改造成本从低到高选以下方案：

方案1：快速适配（零代码/基础设施改动） #

如果你的测量目标只是观测时延波动、做性能趋势分析，不需要绝对精准的单向时延值，直接取连续观测窗口（比如5分钟）内测到的最小延迟值作为基线偏移量，所有后续测量值统一减去这个基线即可。
比如你观测到历史最低延迟是-30ms，就给所有计算结果加30ms，最终得到的结果不会出现负数，也能准确反映网络时延的相对变化，适合快速落地的场景。

方案2：应用层校正（零基础设施依赖，精度最高） #

不需要依赖全局时钟同步，通过往返探测计算两端的时钟偏移量，做动态校正即可：

1. 客户端侧所有本地耗时统计替换Date.now()为performance.now()：这个API返回浏览器单调时钟的计时值，从页面加载完成开始单调递增，不会被系统时间调整影响，不会出现回拨，精度可达微秒级，比Date.now()更适合做时延测量。
2. WebSocket连接建立后，定期（每10~30秒一次）发送时延探测包：
   • 客户端记录发送探测包时的本地单调时钟时间t0
   • 服务端收到探测包后，立刻在响应里写入服务端当前的墙上时钟时间t_server
   • 客户端收到探测响应的第一时间，记录本地单调时钟时间t1
3. 按以下公式计算时钟偏移：

   rtt = t1 - t0 // 探测包往返总耗时
   clockOffset = t_server - (t0 + rtt/2) // 客户端时钟相对服务端的偏移量
   

4. 后续计算真实网络时延的时候，扣除偏移量即可：

   NetworkLag = (receivedAtTime - sentAtTime) - clockOffset
   

这个方案可以把时延测量误差控制在毫秒级，完全消除负数值，不受时钟跳变、设备时钟偏移的影响。

方案3：基础设施层时钟同步（长期最优解） #

给内网所有服务器、员工终端统一配置内网自建的NTP时间源，强制所有设备定期同步，常规配置下可以把跨设备时钟偏移控制在1~5ms；如果是对时延精度要求更高的交易类场景，可以在内网部署PTP精确时间协议服务，能做到亚毫秒级的时钟同步，从根源上消除时钟偏移问题。
注意：哪怕做了严格的时钟同步，也建议客户端侧用performance.now()替代Date.now()做接收时间打点，避免偶发的时钟回拨、跳变影响测量结果。

内容的提问来源于stack exchange，提问作者Rahul Misra