最稳妥的签名算法是HMACSHA256，需共享密钥、严格参数归一化（字典序、UTF-8、过滤空值）、排除sign字段，必含timestamp和nonce防重放，签名放X-Signature头并Base64编码，验签应在中间件中统一处理。
签名用 HMACSHA256 最稳妥，别碰 MD5 或手写拼接
后端加签验签的核心是「双方共享密钥 + 确定性摘要算法」，HMACSHA256 是 C# 生态里最常用、.NET 原生支持、且抗碰撞能力足够应对 API 场景的选择。用 MD5 或 SHA1 属于自降安全水位，哪怕只是内部系统也建议直接跳过；更别提自己拼字符串再哈希——顺序、空格、编码不一致就会验签失败。
实操建议：
-
HMACSHA256的密钥必须是byte[]，别传字符串进去就完事，要用Encoding.UTF8.GetBytes("your-secret") - 签名原文必须严格按约定排序（如字典序）、过滤空值、统一编码（全部
UTF-8），否则前后端算出的哈希值必然不同 - 不要在签名原文里包含
sign字段本身，否则会形成循环依赖 - 推荐把时间戳
timestamp和随机串nonce作为必参参与签名，用于防重放
验签时先校验 timestamp 和 nonce，再算签名
验签不是“算完哈希比对就结束”。如果跳过时效性和唯一性校验，攻击者截获一次合法请求就能无限重放——哪怕签名没错。
实操建议：
- 检查
timestamp是否落在允许窗口内（如 ±5 分钟），用DateTimeOffset.UtcNow.ToUnixTimeSeconds()做对比，避免本地时区误差 - 用 Redis 或内存缓存记录已见过的
nonce（带过期时间），重复即拒，注意缓存键要包含用户 ID 或 app ID 防止跨账号冲突 - 验签前务必确保所有参数已从请求中完整提取（Query + Body JSON 合并），且 key 全部小写或统一格式，否则排序和拼接会错位
- Body 是 JSON 时，别直接取原始字符串——要反序列化再序列化一次（用
JsonSerializer.Serialize），避免空格、换行、字段顺序差异影响哈希
HttpClient 发起请求时，签名要放在 Header 而非 Query
把签名塞进 URL 查询参数（如 ?sign=xxx）看似简单，但实际埋雷：URL 编码不一致、代理/网关自动解码、CDN 截断长 URL、日志误记敏感信息……全都会导致验签失败或泄露密钥逻辑。
实操建议：
- 签名值统一放进自定义 Header，例如
X-Signature，服务端从HttpContext.Request.Headers["X-Signature"]读取 - Header 值建议 Base64 编码（不用 URL-safe 变种），避免特殊字符被中间件误处理
- 如果必须兼容老接口走 Query，至少把
sign参数挪到最后，并在文档里明确要求客户端不对其做额外编码 - 别在 Header 里传密钥或原始
nonce，只传签名结果和必要上下文（timestamp、app_id）
ASP.NET Core 中间件里做验签，别写在 Controller 里
验签是横切关注点，混进业务 Controller 会导致逻辑耦合、异常处理混乱、单元测试难写，而且容易漏掉某些路由（比如没加 [ApiController] 的旧接口）。
实操建议：
- 写一个
SignatureValidationMiddleware，在Program.cs中用app.UseMiddleware<signaturevalidationmiddleware>()</signaturevalidationmiddleware>注册，确保所有请求都过一遍 - 中间件里提前读取 Body 流（用
Request.EnableBuffering()），否则后续 Controller 拿不到内容；记得调用req.Body.Position = 0复位流位置 - 验签失败直接
context.Response.StatusCode = 401并return，别抛异常——避免触发全局异常处理器干扰状态码 - 密钥别硬编码，从
IConfiguration或IOptionsSnapshot获取，支持按app_id动态加载不同密钥
验签逻辑看着简单，真正上线后最常出问题的不是哈希算法，而是参数归一化细节、Body 流读取时机、以及缓存 nonce 的并发清理策略——这些地方一旦出错，现象都是“偶发验签失败”，排查起来特别吃时间。
