签名是怎么算出来的：参与要素与排列顺序

签名可以理解为：把请求内容用一个只有双方知道的材料，算出一段不可逆的摘要。接收方用同样的方法再算一次，两次一致才认为内容未被改动。

一次签名涉及哪些要素

同样的参数用不同顺序拼接，得到的字符串不同，算出的摘要自然也不同。因此文档通常会明确规定排序规则，常见的有按字段名升序、按文档顺序两种。

排序规则的价值在于确定，而不在于某种特定顺序本身。只要双方一致，升序还是降序并不重要。

这三类是签名实现中分歧最多的地方，也是联调阶段最耗时的部分。

经验上看，验签失败里相当大的比例与编码有关：中文字符在不同编码下字节不同，算出的摘要自然不同。

一个基本原则：密钥用于计算摘要，但不会出现在请求内容里。接收方用自己保存的同一份密钥独立计算，再比对结果。

如果密钥出现在请求里，那么任何一方截获请求都能拿到它，签名机制就失去了意义。

联调签名时，最有效的方法是先用一个极简请求：只带必填字段，把待签名串完整打印出来，与文档示例或对方提供的样例逐字比对。最简单的请求通过了，再逐步加字段，比一上来就用完整参数排查要快得多。

签名能证明内容未被改动，但不能证明请求来自合法主体之外的一切问题。完整的防护通常还包括传输层加密、身份标识与权限校验三个部分。四者各管一段，缺任何一段都会留下缺口。

签名机制的价值在于把「内容是否被改动」变成一个可以客观验证的问题。理解它的组成与常见陷阱，联调阶段能省下的时间远超想象。