时间戳为什么要参与签名：防重放与超时窗口

时间戳看起来只是个附加字段，实际上它同时承担着两项职责，缺了它，签名的保护能力会明显下降。

两项职责

层面	防的是什么	机制
参与签名	内容被替换	改时间就要改签名
超时窗口	请求被重放	超出窗口直接拒绝

假如签名不包含时间，那么一条被截获的合法请求，其内容与签名都是有效的，攻击者可以在任何时候重新发送它，而接收方无法判断这是不是一次新的意图。

这就是重放：不是伪造，而是把旧的合法请求再用一次。

窗口太短，正常请求可能因为网络延迟被拒；窗口太长，重放的风险窗口就大。常见的做法是设定一个既能容纳正常网络延迟，又不至于过于宽松的值。

服务器时间不准，会表现为一批请求莫名其妙被拒，而且时好时坏，排查起来非常费时。

这三项属于基础环境，应当在接入前就确认完毕，而不是等到出问题再查。

时间戳的表示方式需要双方一致，常见的有两种：秒级整数与毫秒级整数。

格式	特点	注意点
秒级	长度较短，可读性好	精度到秒，密集请求可能相同
毫秒级	精度更高	与秒级混用会直接导致超时判断错误

两种格式本身没有优劣，但混用一定出问题——毫秒值被当成秒值解读，得到的时刻会远在未来，请求会被判定为超出窗口。

两者都用于对抗重复，但角度不同：时间戳把请求限制在一个有效窗口内，幂等键则在更长时间内识别同一次意图。

窗口挡住的是「很久以前的请求又被发了一次」，幂等键挡住的是「刚才的请求被发了两次」。两者互补，不能互相替代。

时间戳应当取自发起请求时的本地时刻，并在整个请求生命周期内保持不变。如果在重试时重新取值，会导致同一意图对应多个时间，给后续追踪带来困扰。更稳妥的做法是：一次业务意图确定一个时间，重试时沿用原值。

这三类故障的共同点是：业务参数看起来完全正确，问题却出在最基础的时间上。这恰恰说明基础环境检查不该被跳过。

建议在部署流程中加入时间检查这一步：新机器上线前先确认时钟同步正常，而不是等到接口报错再回头查。这个动作成本极低，却能避免一类非常难排查的问题。

时间戳是接口里最不起眼却最容易引发批量故障的字段。把它当成基础设施对待，而不是一个简单的参数，能避开一整类难以定位的问题。