system.currenttimemillis() 是防重放攻击中用于校验时间戳时效性、管理 nonce 生命周期及绑定签名的高精度时间原料，需配合 ntp 同步与缓存清理策略。
用 System.currentTimeMillis() 实现防重放攻击，关键不是“拿它当钟表用”，而是把它当作一个高精度、低开销、全局单调递增的“时间原料”，嵌入到校验逻辑中，配合其他要素形成闭环。
时间戳时效性校验（最基础且必须）
客户端在请求头或参数中携带 X-TIMESTAMP（由前端 Date.now() 生成），服务端立即调用 System.currentTimeMillis() 获取当前服务端时间，计算偏差：
- 取绝对值：
long diff = Math.abs(serverTime - clientTimestamp) - 设定合理窗口：一般为 3000ms（3秒）到 300000ms（5分钟），秒杀等强实时场景建议 ≤5000ms
- 若
diff > timeWindow，直接拦截，返回“请求已过期”
注意：该机制仅防“明显过时”的重放，无法阻止同一窗口内的重复请求，必须搭配唯一性标识。
Nonce + 时间戳双因子校验（生产推荐）
单纯靠时间戳不够，需引入一次性随机数（nonce）保证请求唯一性。服务端用 currentTimeMillis() 辅助管理其生命周期：
- 客户端每次请求生成唯一
nonce（如 UUID 或 16 字节随机数），并附带当前时间戳 - 服务端校验时间戳有效性后，再检查该
nonce是否已在缓存中存在 - 缓存使用
ConcurrentHashMap<string long></string>，value 存入System.currentTimeMillis()记录首次接收时间 - 清理策略：后台定时扫描，剔除
currentTimeMillis() - storedTime > cacheTTL的旧nonce（如 TTL=1小时）
这样既避免内存无限增长，又确保每个 nonce 在有效期内只被接受一次。
签名验证中绑定时间戳（防篡改+防重放）
签名本身不防重放，但把时间戳作为签名原文的一部分，就能让签名具备时效性：
- 客户端签名原文包含：
timestamp + nonce + method + path + sortedParams + secretKey - 服务端收到后，先校验
timestamp是否在窗口内；通过后再用相同规则重算签名比对 - 攻击者即使截获请求，也无法修改
timestamp后仍通过签名——改大了超时，改小了验签失败 -
currentTimeMillis()在这里不参与计算，但它是整个校验流程启动和判断的“锚点”
分布式环境下的注意事项
单机用 currentTimeMillis() 没问题，但多节点部署时要注意：
- 各节点系统时间必须同步（NTP 服务强制校准，误差控制在 ±50ms 内）
- 避免手动修改系统时间或虚拟机暂停，否则可能触发时钟回拨，导致合法请求被误拒
- 高可靠场景可考虑补充
System.nanoTime()做本地单调性兜底（如检测回拨后临时拒绝） - 生产级
nonce缓存应迁移到 Redis，用ZSET存储nonce和时间戳，利用ZREMRANGEBYSCORE自动清理
