1. 为什么你看到的“Sign参数”从来不是随便拼出来的你在调试一个电商后台接口时发现每次 POST 请求体里都带着一个叫sign的字段值像一串随机字符串a7f3e9b2c8d1e4f6a0b9c8d7e6f5a4b3。你试着删掉它返回{code:401,msg:Invalid sign}你把时间戳改小1秒返回{code:400,msg:Timestamp expired}你把请求体 JSON 里商品价格从99.9改成100哪怕其他全没动sign验证也直接失败。这时候你才意识到这个sign不是装饰品它是整套通信链路上最硬的一道锁。它背后是一整套服务端主动防御体系的核心环节——不是防君子而是精准识别并拦截机器流量、批量爬虫、恶意重放和参数篡改。它不依赖 IP 封禁容易误伤、不靠 User-Agent 检查太容易伪造、也不靠前端混淆JS 可被逆向而是用确定性加密时效约束上下文绑定三重机制在请求发起那一刻就完成身份与意图的联合校验。关键词就三个反爬虫、POST 请求参数、Sign 加密机制。这篇文章就是为你拆开这把锁的内部结构——不是讲“怎么用现成 SDK”而是带你亲手设计、实现、验证一个带 Sign 校验的网站后端从算法选型、密钥管理、时间窗口控制到常见绕过手法的对抗策略全部基于我过去三年在中大型电商平台做风控中间件的真实落地经验。无论你是刚接触接口安全的前端开发者还是需要加固 API 的后端工程师或是正在写爬虫但想真正理解对方防线逻辑的从业者这篇内容都能让你看清 Sign 机制到底在防什么、怎么防、以及为什么你之前写的“模拟 sign 生成”总在第三天就失效。2. Sign 的本质不是加密而是“可验证的签名”很多人一看到sign就下意识说“这是 MD5 加密”或“RSA 加密”这是根本性误解。Sign 不是加密encryption而是数字签名digital signature。加密的目标是“不让别人看懂”而签名的目标是“让别人能验证你没改过”。举个生活例子你手写一份报销单签上名字——这签名本身不隐藏金额但财务拿到单子能比对笔迹确认是不是你本人所签、有没有被涂改。Sign 就是这份“电子笔迹”。它的数学基础是哈希函数 密钥。核心流程只有三步标准化拼接把所有参与校验的参数如timestamp1717023456,nonceabc123,data{id:123,price:99.9}按约定规则通常是字典序升序拼成一个字符串比如data%7B%22id%22%3A123%2C%22price%22%3A99.9%7Dnonceabc123timestamp1717023456密钥加盐哈希用服务端持有的私有密钥如SECRET_KEY x9F#kL2mpQ7vR!作为 salt对上述字符串做 HMAC-SHA256 运算输出摘要取运算结果的十六进制表示即为最终sign值。提示HMACHash-based Message Authentication Code是业界标准方案它比简单MD5(secretparams)安全得多——后者存在长度扩展攻击风险而 HMAC 通过两次哈希嵌套彻底规避。我们来实测一个具体例子。假设请求体为{ order_id: ORD-2024-7890, amount: 299.0, currency: CNY, timestamp: 1717023456, nonce: t7xK9mP2 }约定参与签名的字段为order_id,amount,currency,timestamp,nonce注意sign字段本身永远不参与签名否则形成循环依赖排序后拼接字符串URL 编码处理特殊字符amount299.0currencyCNYnoncet7xK9mP2order_idORD-2024-7890timestamp1717023456使用 Python 的hmac模块计算import hmac import hashlib import urllib.parse secret_key bx9F#kL2mpQ7vR! params_str amount299.0currencyCNYnoncet7xK9mP2order_idORD-2024-7890timestamp1717023456 sign hmac.new(secret_key, params_str.encode(), hashlib.sha256).hexdigest() # 输出e8a3b7c1d2f4e5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0这个sign值会被附加到请求头如X-Sign: e8a3b7...或请求体中服务端收到后用完全相同的逻辑重算一遍比对结果是否一致。只要任意一个参数被篡改、顺序错乱、或密钥错误签名必然不匹配。2.1 为什么必须强制排序——参数顺序的陷阱很多初学者会忽略排序这一步直接json.dumps(data)后拼接。问题在于Python 的dict在 3.7 虽然保持插入顺序但 JSON 规范本身不保证对象属性顺序。前端 JS 的JSON.stringify({a:1,b:2})和{b:2,a:1}可能生成不同字符串导致同一份数据算出两个sign。更隐蔽的是某些语言如 Go 的map遍历顺序是随机的。我曾在线上遇到过一个 BugiOS 端用NSJSONSerialization生成的 JSON 字符串字段顺序与 Android 端Gson不一致结果 Sign 校验在 iOS 上 100% 通过Android 却失败率 30%。最后定位到就是没做标准化排序。解决方案很简单所有参与签名的键名必须先排序再拼接。实际代码中不能依赖json.dumps的输出而要显式提取键值对# 正确做法手动构建有序参数字符串 params_dict { order_id: ORD-2024-7890, amount: 299.0, currency: CNY, timestamp: 1717023456, nonce: t7xK9mP2 } # 排序键名 sorted_keys sorted(params_dict.keys()) # 拼接key1value1key2value2... params_list [] for k in sorted_keys: v params_dict[k] # 对 value 做 URL 编码防止 等符号破坏结构 encoded_v urllib.parse.quote(str(v), safe) params_list.append(f{k}{encoded_v}) params_str .join(params_list)2.2 为什么用 HMAC-SHA256而不是 MD5 或 RSA算法选型不是拍脑袋决定的。我们对比三种常见方案方案安全性性能实现复杂度适用场景MD5(secretparams)⚠️ 低易受长度扩展攻击且 MD5 已被证明碰撞可行⚡ 极快✅ 极简仅限内网测试环境生产环境严禁RSA 签名✅ 高非对称加密私钥签名、公钥验签 慢大数运算耗 CPU❌ 高需密钥对管理、PKCS#1 填充等需要强身份认证的金融级接口如银行支付回调HMAC-SHA256✅ 高基于 SHA256目前无实用碰撞攻击HMAC 结构抗长度扩展⚡ 快硬件加速支持好✅ 中等标准库普遍支持绝大多数 Web/API 场景的黄金标准我所在团队曾做过压测在 4 核 8G 的 NginxLua 环境下HMAC-SHA256 签名耗时稳定在 0.08ms而同等条件下 RSA-PSS 签名高达 3.2ms。对于 QPS 5000 的商品详情页接口这点延迟差异直接导致平均响应时间从 45ms 拉高到 68ms。更重要的是RSA 需要管理私钥分发、轮换、吊销而 HMAC 只需同步一个 secret key运维成本低一个数量级。所以除非你的业务明确要求“不可抵赖性”比如法律存证否则 HMAC-SHA256 是唯一理性选择。2.3 Sign 里必须包含哪些参数——校验维度的取舍不是所有参数都要塞进 Sign。原则是凡是可能被篡改、且篡改后会导致业务风险的字段必须参与签名。我们按风险等级分类必含项无条件timestamp毫秒级时间戳用于时效性校验后文详述nonce一次性的随机字符串如 UUID v4防止重放攻击所有业务关键参数如订单 ID、价格、用户 ID、商品 SKU。可选项按需user_token或session_id如果 Sign 用于用户态接口加入可绑定用户身份防止 token 被盗用后批量刷单client_ip增加 IP 绑定但要注意代理场景下获取真实 IP 的可靠性app_version限制特定版本客户端调用便于灰度发布。禁止项sign自身循环依赖signature、hmac等同义字段避免命名冲突敏感字段明文如密码、身份证号——Sign 不解决传输加密这些必须走 HTTPS 前端脱敏。一个典型错误是只对timestamp和nonce签名而把price放在签名外。攻击者完全可以抓包拿到合法请求修改price0.01后重发只要timestamp和nonce没过期服务端就认为“签名有效”导致资损。我在某次安全审计中就发现一个优惠券领取接口存在此漏洞黑产用自动化脚本每天薅走价值数万元的券。3. 设计一个可落地的 Sign 校验网站从零搭建后端服务现在我们动手实现一个最小可行的带 Sign 校验的网站。技术栈选Python Flask Redis用于 nonce 防重放原因很实在Flask 轻量、调试快Redis 的SETNX命令天然适合实现分布式 nonce 检查。整个服务只需 3 个核心接口/api/order/create创建订单需 Sign、/api/order/status查询状态需 Sign、/debug/sign-test调试用返回当前 Sign 计算逻辑。3.1 服务初始化与密钥管理首先建立项目结构sign-demo/ ├── app.py # 主应用 ├── config.py # 配置含 SECRET_KEY ├── utils/ │ ├── sign_utils.py # 签名/验签核心逻辑 │ └── redis_client.py # Redis 连接封装 └── requirements.txtconfig.py中密钥绝不能硬编码import os from datetime import timedelta class Config: # 从环境变量读取本地开发用 .env 文件 SECRET_KEY os.environ.get(SIGN_SECRET_KEY) or dev-secret-key-change-in-prod # 时间窗口允许客户端时间与服务端偏差 ±5 分钟 TIMESTAMP_SKEW timedelta(minutes5) # nonce 有效期15 分钟过期自动清理 NONCE_TTL 900 # seconds注意SECRET_KEY必须满足密码学强度。我推荐用openssl rand -base64 32生成 32 字节随机字符串而非自己编造“复杂密码”。因为人脑设计的“复杂”往往有规律如大小写数字符号交替而真随机才是安全基石。3.2 核心验签逻辑utils/sign_utils.py这是整个系统的“心脏”必须兼顾正确性、可读性和可测试性import hmac import hashlib import time import urllib.parse import json from typing import Dict, Any, Optional from datetime import datetime, timezone from config import Config def generate_sign(params: Dict[str, Any], secret_key: str) - str: 生成 sign 值供前端或测试工具调用 # 1. 过滤掉 sign 自身及空值参数 filtered_params {k: v for k, v in params.items() if k ! sign and v is not None} # 2. 标准化键名排序 值 URL 编码 sorted_keys sorted(filtered_params.keys()) param_pairs [] for k in sorted_keys: v filtered_params[k] # 处理嵌套 dict/list转为 JSON 字符串再编码 if isinstance(v, (dict, list)): v json.dumps(v, separators(,, :), sort_keysTrue) encoded_v urllib.parse.quote(str(v), safe) param_pairs.append(f{k}{encoded_v}) params_str .join(param_pairs) # 3. HMAC-SHA256 计算 sign hmac.new( secret_key.encode(), params_str.encode(), hashlib.sha256 ).hexdigest() return sign def verify_sign( raw_params: Dict[str, Any], secret_key: str, redis_clientNone ) - tuple[bool, str]: 验证 sign 是否有效 返回 (是否通过, 错误信息) # 1. 检查必要参数是否存在 if sign not in raw_params: return False, Missing sign parameter required_fields [timestamp, nonce] for field in required_fields: if field not in raw_params: return False, fMissing required field: {field} # 2. 时间戳校验检查是否在允许偏差范围内 try: client_ts int(raw_params[timestamp]) server_ts int(time.time()) if abs(client_ts - server_ts) Config.TIMESTAMP_SKEW.total_seconds(): return False, fTimestamp expired: client{client_ts}, server{server_ts} except (ValueError, TypeError): return False, Invalid timestamp format # 3. Nonce 防重放检查是否已存在Redis SETNX nonce str(raw_params[nonce]) if redis_client: # 使用 Redis 的 SETNXset if not exists原子操作 # key 格式nonce:{nonce_value} key fnonce:{nonce} # 设置过期时间避免内存泄漏 if not redis_client.set(key, 1, exConfig.NONCE_TTL, nxTrue): return False, Nonce already used # 4. 生成待验签字符串同 generate_sign 逻辑 # 注意这里必须和前端/客户端完全一致 filtered_params {k: v for k, v in raw_params.items() if k ! sign} sorted_keys sorted(filtered_params.keys()) param_pairs [] for k in sorted_keys: v filtered_params[k] if isinstance(v, (dict, list)): v json.dumps(v, separators(,, :), sort_keysTrue) encoded_v urllib.parse.quote(str(v), safe) param_pairs.append(f{k}{encoded_v}) params_str .join(param_pairs) # 5. 计算期望的 sign expected_sign hmac.new( secret_key.encode(), params_str.encode(), hashlib.sha256 ).hexdigest() # 6. 安全比对防止时序攻击 # 使用 hmac.compare_digest它执行时间恒定避免通过响应时间差推断 sign if not hmac.compare_digest(expected_sign, raw_params[sign]): return False, Invalid sign return True, Success这段代码有几个关键细节值得深挖hmac.compare_digest的必要性普通比较是“短路”的——从左到右逐字符比对一旦发现不同立即返回False。攻击者可以通过测量响应时间纳秒级差异逐步爆破出正确的sign值称为时序攻击。compare_digest内部会完整比对所有字节确保时间恒定。json.dumps(..., sort_keysTrue)确保嵌套 JSON 字符串的字段顺序一致避免因解析器差异导致签名不一致。urllib.parse.quote(..., safe)safe表示不保留任何字符包括/?等全部编码杜绝 URL 解析歧义。3.3 Flask 路由实现app.py现在把验签逻辑接入路由from flask import Flask, request, jsonify from utils.sign_utils import verify_sign from utils.redis_client import get_redis_client from config import Config app Flask(__name__) app.route(/debug/sign-test, methods[GET]) def debug_sign_test(): 调试接口返回当前签名规则说明 return jsonify({ message: Sign verification rule, required_params: [timestamp, nonce, sign], timestamp_skew: f±{int(Config.TIMESTAMP_SKEW.total_seconds())} seconds, nonce_ttl: f{Config.NONCE_TTL} seconds, algorithm: HMAC-SHA256, example_params: { order_id: ORD-2024-001, amount: 99.99, timestamp: 1717023456, nonce: a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8, sign: e8a3b7c1d2f4e5a6b7c8d9e0f1a2b3c4d5e6f7a8b9c0d1e2f3a4b5c6d7e8f9a0 } }) app.route(/api/order/create, methods[POST]) def create_order(): # 1. 解析请求体支持 JSON 和 form-data if request.is_json: data request.get_json() else: data request.form.to_dict() # 处理多值字段如文件上传此处简化为单值 # 2. 获取 Redis 客户端 redis_client get_redis_client() # 3. 验签 is_valid, msg verify_sign(data, Config.SECRET_KEY, redis_client) if not is_valid: return jsonify({code: 401, msg: msg}), 401 # 4. 业务逻辑创建订单此处简化为返回 mock 数据 order_id fORD-{int(time.time())}-{data.get(nonce, xxx)[:6]} return jsonify({ code: 200, data: { order_id: order_id, status: created, timestamp: int(time.time()) } }) app.route(/api/order/status, methods[GET]) def order_status(): # GET 请求参数在 args 中 params request.args.to_dict() redis_client get_redis_client() is_valid, msg verify_sign(params, Config.SECRET_KEY, redis_client) if not is_valid: return jsonify({code: 401, msg: msg}), 401 # 业务逻辑查询订单状态 order_id params.get(order_id) return jsonify({ code: 200, data: { order_id: order_id, status: paid, paid_at: 2024-05-30T10:20:30Z } }) if __name__ __main__: app.run(debugTrue, host0.0.0.0, port5000)3.4 Redis 防重放的工程实践utils/redis_client.pynonce防重放看似简单但在高并发下极易出错。我们用 Redis 的SETNXSet if Not eXists命令实现原子性检查import redis from config import Config _redis_client None def get_redis_client(): global _redis_client if _redis_client is None: _redis_client redis.Redis( hostos.environ.get(REDIS_HOST, localhost), portint(os.environ.get(REDIS_PORT, 6379)), dbint(os.environ.get(REDIS_DB, 0)), decode_responsesTrue, socket_connect_timeout2, socket_timeout2 ) # 测试连接 try: _redis_client.ping() except redis.ConnectionError: raise RuntimeError(Cannot connect to Redis) return _redis_client注意SETNX是原子操作但必须配合EX过期时间参数否则一旦某个nonce写入 Redis 后服务崩溃该nonce将永久存在导致后续所有请求失败。我们设置ex90015分钟既防重放又避免内存无限增长。4. 攻击者视角常见绕过 Sign 校验的手法与防御加固设计完系统必须站在攻击者角度思考他们怎么破我见过太多团队花一周写完 Sign 校验上线三天就被绕过。不是算法不行而是工程落地时漏掉了关键防护点。下面复盘几个真实发生过的绕过案例以及对应的加固方案。4.1 案例一时间戳宽松导致“永不过期”签名现象某活动页面接口timestamp校验只检查abs(client_ts - server_ts) 3005分钟但攻击者发现服务器时间比 NTP 标准慢 8 分钟。于是他构造timestamp server_ts 300即比服务器当前时间快 5 分钟这个签名在服务器看来“刚刚好”且由于服务器时间慢实际有效期长达 13 分钟。黑产用这个“长时效签名”批量刷取限量商品。根因分析只校验时间差未校验时间方向。正确做法是client_ts必须小于等于server_ts skew且大于等于server_ts - skew即server_ts - skew client_ts server_ts skew。但更根本的解法是服务端永远以自身时间为权威拒绝未来时间戳。因为未来时间戳没有任何业务合理性用户不可能预知未来事件且能彻底杜绝此类“时间差利用”。加固代码修改verify_sign中的时间校验部分# 替换原有时序校验 server_ts int(time.time()) client_ts int(raw_params[timestamp]) # 严格拒绝未来时间戳 if client_ts server_ts Config.TIMESTAMP_SKEW.total_seconds(): return False, fFuture timestamp rejected: client{client_ts}, server{server_ts} if client_ts server_ts - Config.TIMESTAMP_SKEW.total_seconds(): return False, fExpired timestamp: client{client_ts}, server{server_ts}4.2 案例二Nonce 存储未隔离导致跨接口重放现象一个用户注册接口/api/user/register和一个支付接口/api/pay/submit共用同一套nonce校验逻辑。攻击者先调用注册接口拿到一个合法nonce然后把这个nonce用在支付接口上成功绕过防重放。根因分析Nonce 应与业务上下文强绑定。一个用于注册的随机数绝不该能用于支付。解决方案是nonce的 Redis Key 中加入业务标识前缀如nonce:register:{value}和nonce:pay:{value}。加固代码修改verify_sign中的 Redis 操作# 原逻辑 # key fnonce:{nonce} # 加固后根据请求路径动态生成前缀 # 注意需在路由中传入 context此处简化为从 request.path 提取 context request.path.split(/)[2] # /api/order/create - order key fnonce:{context}:{nonce}4.3 案例三Sign 计算逻辑泄露导致“白盒破解”现象某 App 的 Sign 生成逻辑被逆向出攻击者发现其算法是MD5(timestamp secret order_id)且secret硬编码在 APK 中。黑产直接用 Python 复刻了整个签名过程日均调用 200 万次。根因分析前端参与 Sign 计算是高危行为。一旦客户端代码可被逆向Android APK、iOS IPA、Web JSsecret和算法就等于公开。正确架构是Sign 由服务端生成并下发客户端只负责透传。例如下单前先调用/api/order/pre-sign服务端返回order_id、timestamp、nonce和sign客户端拿着这四个值去调/api/order/submit。但这带来新问题/api/order/pre-sign接口本身也需要防刷。解决方案是对该接口做轻量级风控如限制 IP 频率10次/分钟、要求登录态、或引入简单验证码非图形可用滑动验证。这样就把“密钥保护”从“防逆向”降级为“防暴力”难度指数级下降。4.4 案例四JSON 参数解析歧义导致签名绕过现象接口接收 JSON 请求体但后端用json.loads(request.data)解析而前端发送时用了application/json但 body 是{price:99.9}字符串和{price:99.9}数字两种格式。服务端验签时用str()强转导致price:99.9和price:99.9算出的sign不同但业务逻辑中price都被转为 float 处理造成“签名有效但业务异常”。根因分析JSON 类型不一致是签名系统的隐形杀手。数字99.9和字符串99.9在 JSON 中语义不同但业务层常做隐式转换。解决方案是验签时必须使用与业务层完全一致的数据形态。如果业务层把price当作 float 处理那么验签时也必须先把price字符串float()再参与拼接。加固代码在verify_sign的参数处理中# 对已知数值型字段做强制类型转换再参与签名 numeric_fields [amount, price, quantity, timestamp] for field in numeric_fields: if field in filtered_params: try: # 尝试转为 float再转回字符串保持精度 filtered_params[field] str(float(filtered_params[field])) except (ValueError, TypeError): pass # 无法转换则保持原样由业务层报错5. 实战调试与线上巡检让 Sign 系统真正可靠写完代码只是开始Sign 系统的价值体现在线上稳定运行。我总结了一套从开发到线上的全流程保障方法这些不是文档里的“最佳实践”而是我在凌晨三点排查线上故障时用血泪换来的经验。5.1 本地调试用 curl 模拟完整请求链别依赖 Postman 点点点。用curl写脚本才能暴露真实问题。以下是一个可直接运行的调试脚本test_sign.sh#!/bin/bash # 生成当前时间戳和 nonce TIMESTAMP$(date %s) NONCE$(uuidgen | tr [:upper:] [:lower:]) # 构造原始参数不含 sign PAYLOAD{ order_id: TEST-$TIMESTAMP, amount: 1.0, currency: CNY, timestamp: $TIMESTAMP, nonce: $NONCE } # 用 Python 计算 sign复用你的 sign_utils.generate_sign SIGN$(python3 -c import sys, json sys.path.append(.) from utils.sign_utils import generate_sign params json.loads($PAYLOAD) print(generate_sign(params, x9F#kL2mpQ7vR!)) ) # 发送请求 curl -X POST http://localhost:5000/api/order/create \ -H Content-Type: application/json \ -d { \order_id\: \TEST-$TIMESTAMP\, \amount\: 1.0, \currency\: \CNY\, \timestamp\: $TIMESTAMP, \nonce\: \$NONCE\, \sign\: \$SIGN\ }运行它你会立刻看到如果SIGN计算错误返回401 Invalid sign如果timestamp超出范围返回401 Timestamp expired如果nonce重复返回401 Nonce already used。提示把SIGN计算逻辑单独抽成 CLI 工具开发时./gen-sign.py --order_id ORD-123 --amount 99.99一键生成效率翻倍。5.2 线上日志记录验签全过程而非只记“成功/失败”很多团队的日志只写Sign verified: true或Sign failed: invalid。这在线上出问题时毫无价值。必须记录验签每一步的中间值# 在 verify_sign 函数中添加详细日志生产环境建议用 structured logging import logging logger logging.getLogger(__name__) def verify_sign(...): logger.info(f[SignVerify] Start with params: {raw_params.keys()}) if sign not in raw_params: logger.warning(f[SignVerify] Missing sign, params: {list(raw_params.keys())}) return False, Missing sign parameter # ... 中间校验步骤 ... logger.info(f[SignVerify] Params string: {params_str}) logger.info(f[SignVerify] Expected sign: {expected_sign}) logger.info(f[SignVerify] Received sign: {raw_params[sign]}) if not hmac.compare_digest(expected_sign, raw_params[sign]): logger.error(f[SignVerify] Sign mismatch! Expected: {expected_sign[:8]}..., Got: {raw_params[sign][:8]}...) return False, Invalid sign这样当某天发现大量Invalid sign时你 grep 日志就能看到是params_str不一致说明前端拼接逻辑变了还是expected_sign和received sign前8位相同但后面不同说明传输中被截断或编码损坏。5.3 监控告警定义 Sign 系统的 SLO 指标Sign 不是“有就行”它必须满足业务 SLO。我们定义三个核心指标验签成功率sum(rate(sign_verify_failure_total[1h])) / sum(rate(sign_verify_total[1h])) 0.1%99.9% 成功率验签 P95 延迟histogram_quantile(0.95, rate(sign_verify_duration_seconds_bucket[1h])) 50msNonce 冲突率sum(rate(nonce_conflict_total[1h])) / sum(rate(sign_verify_total[1h])) 0.01%。用 Prometheus Grafana 搭建看板当Nonce 冲突率突增时大概率是某个客户端 bug 导致nonce生成逻辑失效如固定值当验签延迟持续高于 50ms可能是 Redis 连接池打满或网络抖动。5.4 定期轮换密钥不是一劳永逸的SECRET_KEY必须定期轮换建议每 3 个月且轮换过程要平滑。不能今天切新 key昨天的请求就全挂。方案是双 key 并行校验。服务端同时持有old_key和new_key验签时先用new_key试失败再用old_key试。轮换期如 7 天后old_key下线。前端需在轮换窗口期内完成更新。代码层面verify_sign函数支持传入keys列表def verify_sign(..., secret_keys: list None): if secret_keys is None: secret_keys [Config.SECRET_KEY] # 默认单 key for key in secret_keys: # 尝试用每个 key 验证 if hmac.compare_digest(expected_sign, raw_params[sign]): return True, Success return False, Invalid sign