接口签名的核心目的是防止请求被篡改、重放或冒用，本质是生成可验证的“数字指纹”；推荐hmac-sha256（开发）或rsa-sha256（上线），需按规则拼接参数、含timestamp和nonce，服务端须校验时效性、唯一性及签名一致性，并强制https与密钥安全存储。
接口签名的核心目的
防止请求被篡改、重放或冒用，本质是让服务端能验证“这个请求确实来自合法客户端，且没被中间人修改过”。关键不在于加密数据，而在于生成一段可验证的“数字指纹”。
常用签名算法组合
推荐使用 HMAC-SHA256（对称密钥）或 RSA-SHA256（非对称密钥），兼顾安全性与性能。开发阶段可用 HMAC，上线后敏感接口建议升级为 RSA，避免密钥泄露风险。
- HMAC 方式：客户端和服务端共享一个 secret_key，对请求参数按规则拼接后计算摘要
- RSA 方式：客户端用私钥签名，服务端用公钥验签，私钥绝不上传、不硬编码在代码里
签名字段与拼接规则（以 HMAC 为例）
不是对整个 body 签名，而是对**参与签名的参数**做确定性排序和拼接。常见要求：
- 只对 query 或 body 中的业务参数签名，排除 timestamp、nonce、signature 自身
- 参数按 key 字典序升序排列，拼成 key1=value1&key2=value2 格式（value 需 URL 编码）
- 必须包含时间戳（timestamp，单位秒或毫秒）和服务端校验窗口（如 ±300 秒）
- 必须包含随机串（nonce），服务端需缓存近期 nonce 防重放（Redis 是常用方案）
示例拼接字符串：api_key=abc&method=get_user×tamp=1715823456&nonce=xyz123&user_id=1001
立即学习“Python免费学习笔记（深入）”；
服务端验签关键检查点
收到请求后，不能只算一次摘要就放行，要逐项防御：
- 检查 timestamp 是否在允许偏差内（防重放）
- 检查 nonce 是否已存在（Redis SETNX + 过期时间，如 5 分钟）
- 根据相同规则重新拼接参数并计算 signature，比对是否一致
- 若用 RSA，还需校验公钥格式、签名长度、证书有效期（如有）
- 验签失败统一返回 401，不暴露具体失败原因（如“nonce 已用”会帮攻击者探测机制）
安全增强实践
签名只是第一道防线，需配合其他措施：
- 所有签名接口强制走 HTTPS，禁止 HTTP 明文传输
- secret_key / private_key 存放在环境变量或密钥管理服务（如 AWS KMS、Vault），不写死在代码或配置文件中
- 客户端 SDK 封装签名逻辑，避免各业务方自行实现出错
- 服务端记录高频验签失败的 client_id / IP，触发限流或告警
不复杂但容易忽略。
