单纯用JWT签名不足以防篡改，因其仅保障Token自身不被修改，无法防止请求体（如amount参数）被截获后篡改并重放；真正防篡改需将请求路径、时间戳、原始body哈希等上下文纳入Token载荷并签名验证。
为什么单纯用JWT签名还不够防篡改
JWT的HS256签名只能保证Token不被第三方修改，但无法防御“重放攻击”或“参数篡改后重复提交”。比如攻击者截获一个合法access_token，再把请求体里的amount=100改成amount=10000发过去——只要接口没校验请求体完整性，就可能执行。
真正防篡改的关键不是Token本身，而是把请求上下文（时间戳、请求路径、body摘要）纳入签名范围。常见错误是只对user_id和exp签名，漏掉body或query_string。
- 必须在服务端重新计算请求的
body哈希（如sha256），并与Token中携带的body_hash比对 - 时间戳
iat和exp需严格校验，窗口建议≤30秒，避免重放 - 不要信任客户端传来的
Content-MD5头，应以服务端解析后的原始字节为准
如何用PyJWT生成带请求指纹的Token
不能只签用户ID，得把关键请求特征打包进去。推荐结构：{'uid': 123, 'path': '/api/v1/transfer', 'ts': 1717023456, 'body_hash': 'a1b2c3...'}，再用PyJWT.encode()签名。
注意body_hash必须基于原始request.get_data()（未解码的bytes），而非request.json（已转成dict，顺序和空格可能变化）。
立即学习“Python免费学习笔记（深入）”；
Token 消耗追踪工具。当用户需要监控 API token 使用情况、生成每日/每周消耗报告、分析使用趋势时使用此 Skill。功能包括：自动记录每次对话的 token 消耗、生成数据表格报告、计算使用趋势和预测、支持定时推送日报。
- 使用
hashlib.sha256(request.get_data()).hexdigest()[:16]生成紧凑哈希 - 签名密钥必须用
secrets.SystemRandom().randbytes(32)生成，别用字符串硬编码 - 设置
algorithm='HS256'，禁用none算法（防范alg=none漏洞）
Flask中验证Token并比对请求指纹
验证流程必须原子化：先解码Token，再立刻校验exp和iat，然后用同一份原始body算哈希，最后才处理业务逻辑。中间任何一步失败都直接abort(401)。
常见坑是先调request.json再取request.get_data()——前者会消耗流，后者返回空bytes，导致哈希不匹配。
- 务必在
before_request里用request.get_data(cache=True)缓存原始body - 用
jwt.decode(token, key, algorithms=['HS256'], leeway=0)关闭自动时间宽容 - 对比
token['path'] == request.path和token['body_hash'] == computed_hash
Body哈希不一致的典型原因和调试方法
开发时最常遇到body_hash校验失败，90%是因为body预处理不一致。比如前端发{"amount":100}，后端却按{"amount": 100}（多了空格）解析，哈希自然不同。
调试时直接打印两段bytes的十六进制：print(request.get_data().hex()) 和 print(json.dumps(data).encode().hex())，一眼看出差异。
- 确保前后端约定body编码为UTF-8，且不带BOM
- 如果用gzip压缩，必须在
get_data()前手动解压，否则哈希对象错位 - 表单提交（
application/x-www-form-urlencoded）需用urllib.parse.parse_qsl(request.get_data().decode())标准化后再哈希
body_hash字段长度、哈希算法选择、时间窗口这些细节，比选什么框架影响更大。多数问题出在“以为body一样，其实bytes不一样”。 
