时间戳校验必须配合HMAC签名才能防重放，需统一用UTC、设300秒窗口、校验存在性/类型/范围，并在签名前完成；客户端和服务端时间、签名格式、编码方式须严格对齐。
Flask接口加时间戳校验前，先确认你真需要它
时间戳校验本身不防重放，只防“过期重放”；它必须配合签名（如 HMAC）才能真正防止篡改+重放。单独比对 timestamp 参数，攻击者只要在有效窗口内重放一次合法请求，照样成功。
常见错误现象：401 Unauthorized 频发，但前端明明传了 timestamp；或测试时正常，上线后大量请求被拒——多半是服务器和客户端时钟不同步，或没统一用 UTC。
- 务必用
datetime.utcnow()生成和比对时间，别用datetime.now() - 时间窗口建议设为
300秒（5 分钟），太短伤体验，太长增风险 - 所有参与签名的字段（含
timestamp）必须按固定顺序拼接，否则签名对不上
如何在 Flask 路由里安全提取并验证 timestamp
别直接从 request.args 或 request.json 读 timestamp 就完事。得先检查它是否存在、是否为数字、是否在合理范围，再进时间差校验。
使用场景：API 需要高一点的安全水位，比如支付回调、敏感操作（删账号、改密码）。
立即学习“Python免费学习笔记（深入）”；
- 用
request.headers.get('X-Timestamp')比 URL 参数更干净，避免日志泄露或 CDN 缓存 timestamp - 转换时用
int(float(timestamp_str))兼容浮点时间戳（JSDate.now()返回毫秒，得除以 1000） - 校验逻辑写成独立函数，别堆在视图里：
def is_timestamp_valid(ts: int, window_s: int = 300) -> bool:
if not is_timestamp_valid(int(ts)):
return {'error': 'Invalid or expired timestamp'}, 401
签名 + 时间戳组合才是防重放的最小可行方案
只校验时间戳，等于给攻击者开了个 5 分钟的重放窗口；加上签名，才能确保“这个 timestamp 确实是本次请求原生携带、没被中间人换过”。
参数差异：签名密钥不能硬编码在代码里，得从环境变量读取（os.environ.get('API_SECRET')）；签名原文必须包含 timestamp、HTTP 方法、路径、body 的摘要（如 hashlib.sha256(request.get_data()).hexdigest()），缺一不可。
- 客户端签名时，时间戳单位要和 Flask 侧一致（推荐秒级整数）
- Flask 侧验证签名前，必须先通过时间戳校验，否则可能耗资源验一个已过期的签名
- 别用
hmac.compare_digest()直接比签名字符串——得先 base64 解码或 hex 解码再比
容易被忽略的兼容性与性能坑
开发时本地测试一切正常，上线后发现 iOS 客户端总失败？大概率是它的系统时间没同步，或者 JS Date.now() 在某些 WebView 里不准。还有更隐蔽的：uWSGI/Gunicorn 多进程下，如果密钥没正确加载到每个 worker，签名会随机失效。
- 不要依赖客户端传的时区信息，所有时间逻辑走 UTC，返回给前端也明确标
Z（如"2024-06-15T12:00:00Z"） - 签名计算放在视图开头，但 body 读取（
request.get_data()）会消耗流，后续再读就为空——需缓存或用request.data - 高频接口慎用完整 body 签名，可改用关键字段签名（如用户 ID + 操作类型 + timestamp），减少哈希开销
真正的难点不在写几行校验代码，而在于客户端和服务端对“时间”“签名格式”“编码方式”的每一处隐式约定，都得对齐。漏掉任意一个，表现就是“有时行，有时不行”。
