hmacsha256 是 c# 中最常用、最稳妥的 hmac 实现方式，但签名总对不上八成因 key 或 message 字节编码不一致，或验证时未用恒定时间比对。
直接说结论：HMACSHA256 是 C# 中最常用、最稳妥的 HMAC 实现方式，但签名总对不上？八成是 key 或 message 的字节编码不一致，或验证时用了字符串比较而非恒定时间比对。
为什么用 HMACSHA256 而不是 HMACMD5 或 HMACSHA1
SHA-256 目前仍是主流平台（如华为云 IoT、阿里云 API 网关、微信支付回调验签）强制或默认要求的哈希算法。MD5 和 SHA1 已被证实存在碰撞风险，部分服务端会直接拒收其生成的签名。
关键点：
-
HMACSHA256类位于System.Security.Cryptography命名空间，.NET Framework 4.6+、.NET Core 2.0+、.NET 5+ 均原生支持，无需额外 NuGet 包 - 不要手动拼接
ipad/opad或实现 XOR 运算——HMACSHA256内部已严格按 RFC 2104 处理密钥扩展、填充与双哈希流程 - 若对接方明确要求
HMAC-SHA256，就别用HMACSHA512替代，哪怕它“更安全”——算法不匹配，签名必然失败
HMACSHA256 构造和签名必须传 byte[]，不能传字符串
这是 C# 开发者踩坑最多的地方：把密钥或消息当字符串直接塞进构造函数，结果签名永远和对方对不上。
实操建议：
- 统一用
Encoding.UTF8.GetBytes("your-key")和Encoding.UTF8.GetBytes("message-body")转换，除非文档明确写“使用 ASCII 编码” - 从 HTTP 请求体读取的
message，要确认是否含 BOM（如 UTF-8 with BOM）、隐藏换行符（\r\nvs\n）、多余空格——这些都会改变字节流 - 如果消息本身是 Base64 字符串（比如 JWT payload），先
Convert.FromBase64String()解码为原始字节，再参与签名；不要对 Base64 字符串本身签名 - 密钥为空（
new byte[0]）或为null会抛ArgumentException或误导性CryptographicException，务必提前校验
验证签名必须用恒定时间比较，禁用 == 或 String.Equals
服务端收到签名后，如果用字符串直接比对（如 receivedSig == computedSig），攻击者可通过响应时间差异推断出签名前缀，实施时序攻击。
正确做法：
- .NET 5+：用
CryptographicOperations.FixedTimeEquals(computedHash, receivedHash)，两个参数都必须是byte[] - 收到的签名通常是 Base64 或十六进制字符串，必须先解码：
Convert.FromBase64String(receivedSig)或HexToBytes(receivedSig) - .NET Framework 或 .NET Core 3.1 及更早版本：手写恒定时间比较逻辑，遍历每个字节做异或再累积或运算，最后判断是否全零——别抄网上“逐个字符比较 + break”的错误实现
- 验证失败时统一返回
401 Unauthorized，不区分“密钥错误”“消息被篡改”“签名格式非法”，避免信息泄露
输出格式选 Base64 还是十六进制？看对接方要求
签名本质是 byte[]，传输前需编码。两种主流格式互不兼容，选错就验签失败。
常见场景：
- HTTP Header（如
X-Hub-Signature-256）通常要求sha256=xxx，其中xxx是 Base64 编码（如 GitHub Webhook） - 某些金融/政务接口（如部分省级政务服务自助终端 API）明确要求小写十六进制字符串（
BitConverter.ToString(hash).Replace("-", "").ToLowerInvariant()） - 不要自己写 Base64 编码逻辑——用
Convert.ToBase64String(hash)即可；十六进制推荐用BitConverter而非string.Concat(hash.Select(b => b.ToString("x2")))，后者在大数组下性能差且易出错 - 调试时可同时打印两种格式，快速定位是编码问题还是算法问题
真正容易被忽略的是：密钥长度虽无硬性上限，但过短（如少于 32 字节）会削弱安全性；而过长（如超 64 字节）会被 HMACSHA256 内部自动哈希截断——这本身合规，但若对接方未做同样处理，就会导致签名不一致。
