最稳方案是用 hash_hmac() 做签名，严格统一参数归一化：ksort 排序、空值保留为 ''、rfc3986 编码、timestamp 必含、signature 不参与签名，客户端与服务端必须完全一致处理空值和编码。
PHP 用 hash_hmac() 做 URL 参数签名最稳
直接说结论：别手写 MD5 拼接，也别用 md5($params . $secret) 这种弱方式。PHP 自带的 hash_hmac() 是标准解法，抗长度扩展攻击、支持多种哈希算法、密钥隔离做得干净。
常见错误是把参数顺序搞乱，或者漏掉空值参数——比如 status= 和 status（没等号）在签名时必须统一处理，否则服务端校验必失败。
- 只对查询参数的 key=value 部分签名，不包含
?和 URL 路径 - 参数必须按字典序（
ksort()）排序后再拼接，否则客户端和服务端结果不一致 - value 中的空格要保持原样（不替换成
+），URL 解码后参与签名，不是编码前 - 推荐用
sha256算法，兼容性好且足够安全；避免用md5或sha1
签名字符串怎么拼：key=value&key=value 格式不能错
拼串看着简单，但线上出问题八成卡在这步。不是 rawurlencode 全部，也不是直接 http_build_query —— 它会把空值转成 key=&...，而有些 SDK 期望 key（无等号）。
正确做法是先规范参数：所有 value 强制转字符串，空值留空（''），再 ksort()，最后用 http_build_query($params, '', '&', PHP_QUERY_RFC3986) 拼接。RFC3986 模式确保空格变 %20 而非 +，和大多数前端 encodeURIComponent 行为对齐。
立即学习“PHP免费学习笔记（深入）”；
- 不要用
urldecode()后再拼 —— 多余且易错，原始参数值（未 decode）就该参与签名 - 如果接口明确要求忽略空参数（如
filter_var($v, FILTER_NULL_ON_FAILURE)），那签名前就得先过滤，否则校验端也要同步过滤 - 时间戳
timestamp建议强制加入签名，用于防重放，单位秒即可
服务端校验时，parse_str() 会丢空值，得手动补
这是线上最隐蔽的坑：parse_str($_SERVER['QUERY_STRING'], $input) 遇到 ?a=&b=1，$input['a'] 是 null 而不是 ''，导致签名字符串和客户端不一致。
必须自己解析 query string，或用 $_GET（它保留空字符串），但要注意 $_GET 已经 urldecode 过 —— 所以签名时也得用 decode 后的值拼串，前后才对得上。
- 推荐统一走
$_GET：客户端签名用http_build_query($params)（默认 decode 行为），服务端直接取$_GET，再ksort()+ 拼串校验 - 如果必须从原始 query string 解析，用
explode('&', $_SERVER['QUERY_STRING'])手动拆，再explode('=', $part, 2)防止 value 里有= - 校验失败时，打印出服务端拼出的待签字符串和客户端传来的签名，比对差异点，别只看“验签失败”四个字
签名加进 URL 后，注意 signature 参数位置不影响验证
signature 本身不参与签名，这是共识。但它在 URL 里放哪？其实无所谓 —— 放最前、中间、最后都行，只要校验时把它从参数中剔除干净再拼串。
容易踩的坑是：用 http_build_query() 生成签名串时，误把 signature 也塞进去了；或者用 array_diff_key() 剔除时键名写错（比如写成 'sig' 而不是 'signature'）。
- 建议封装一个
buildSignString(array $params, array $exclude = ['signature'])函数，复用逻辑 - 别在签名里包含
access_token或api_key这类认证字段 —— 它们属于身份层，签名只管业务参数防篡改 - 如果 URL 本身带 fragment（
#xxx），它根本不会发到服务端，不用管
