验签本质是比对服务端生成的签名和客户端传来的签名是否一致：取原始参数、按规则拼接（排序+过滤空值+rawurlencode）、用密钥生成签名后与sign字段比对，任一环节不一致即失败。
验签本质是比对服务端生成的签名和客户端传来的签名是否一致
PHP后台验签不是加密，而是验证请求来源可信——核心逻辑就三步：取原始参数、按规则拼接、用密钥生成签名、再跟 sign 字段比对。只要中间任意一环（比如参数顺序、空值处理、编码方式）不一致，签名就对不上，这是绝大多数验签失败的根本原因。
拼接参数前必须规范排序和过滤
常见错误是直接用 $_POST 或 $_GET 原样拼接，结果因键名顺序不同或带空值/签名字段本身导致服务端和客户端算出的字符串不一致。
- 务必剔除
sign字段（否则递归了） - 对剩余参数按键名升序排序（
ksort()），不能依赖请求原始顺序 - 过滤掉值为空字符串、
null、false的项（除非协议明确要求保留） - 所有参数值统一做
rawurlencode()（不是urlencode()），避免中文或特殊字符编码差异
示例片段：
$params = array_filter($_GET, function($v) { return $v !== '' && $v !== null && $v !== false; });
unset($params['sign']);
ksort($params);
$buff = '';
foreach ($params as $k => $v) {
$buff .= $k . '=' . rawurlencode($v) . '&';
}
$buff = rtrim($buff, '&');
$expected_sign = hash_hmac('sha256', $buff, $secret_key);
注意 HMAC 算法和密钥传递方式的一致性
客户端用什么算法（hmac-sha256？md5？）、密钥是明文还是 base64 解码后使用，PHP 必须严格对齐。很多联调失败是因为前端用 JS 的 CryptoJS.HmacSHA256，而 PHP 用了 hash_hmac('sha256', ...) —— 这俩默认行为一致，但一旦密钥含非 ASCII 字符或被额外编码，结果就偏了。
- 确认密钥是二进制安全的：如果密钥来自配置文件且含转义字符，用
base64_decode()或hex2bin()预处理 - 避免用
md5($str.$key)这类自定义拼接，它不等价于 HMAC，抗碰撞性差且易受长度扩展攻击 - 若客户端用 AES 加密后再签名，PHP 端必须先解密再验签，不能跳过解密直接对密文验签
验签失败时优先检查 URL 编码和时间戳有效期
90% 的“验签失败但代码看起来没错”问题，实际出在传输层：sign 参数被浏览器或代理二次 URL 解码，或客户端时间偏差太大导致后台拒绝过期请求。
- 用
error_log(print_r($_GET, true))打印原始接收参数，确认sign值没被截断或乱码（尤其含+或%） - 检查客户端是否把
timestamp传成了毫秒级时间戳，而 PHP 后台只接受秒级（time()） - 加个宽松窗口：允许 ±300 秒偏差，用
abs($_GET['timestamp'] - time()) > 300提前拦截，别让签名计算白跑一趟
真正难调试的，往往不是哈希函数写错，而是 rawurlencode() 漏了某一个值，或者 ksort() 前忘了 array_filter() 掉空值——这些细节不打日志根本看不出来。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
