签名验证的核心逻辑是客户端与服务端用相同密钥、相同规则（字典序排序+RFC3986编码+固定字段拼接）对请求参数（含timestamp、nonce等）执行hash_hmac('sha256')生成签名，服务端复现计算并用hash_equals安全比对，同时校验timestamp时效性（如±300秒）和nonce唯一性（Redis去重），确保请求真实、未篡改、不重放。
签名验证的核心逻辑是什么
PHP接口签名验证不是为了加密数据，而是确认请求确实来自你信任的客户端、且没被中间人篡改。关键不在于“多难破解”，而在于“能否低成本识别伪造”。最常用的是对请求参数（含时间戳、随机串、密钥）做 sha256 或 hmac_sha256 摘要，服务端复现计算并比对。
- 签名必须包含
timestamp（如精确到秒），服务端只接受 5 分钟内的请求 - 必须含
nonce（一次性的随机字符串），服务端需缓存近期用过的nonce防重放 - 密钥（
$secret）绝不传给前端，只存在服务端配置或环境变量中
怎么用 hash_hmac 生成和校验签名
hash_hmac 比 sha256 更安全，它天然防长度扩展攻击，也更符合签名场景。客户端和服务端必须用完全一致的参数顺序、编码方式、拼接规则。
// 客户端（伪代码）：按 key 字典序排序参数，拼成 query string 形式
$params = [
'app_id' => 'abc123',
'timestamp' => '1717023456',
'nonce' => 'x8a9b2c',
'data' => '{"id":123}'
];
ksort($params);
$sign_str = http_build_query($params, '', '&', PHP_QUERY_RFC3986);
$signature = hash_hmac('sha256', $sign_str, $secret);
<p>// 服务端收到后，同样排序、拼串、计算，再比对</p>- 参数必须用
http_build_query且指定PHP_QUERY_RFC3986，否则空格变+会导致签名不一致 - 不要对整个 JSON body 做签名——body 可能含换行/缩进差异，应提取关键字段或约定用
data字段传 base64 编码后的 JSON -
hash_hmac返回小写十六进制字符串，直接用===比对，别用==
常见报错：Signature not match 怎么快速定位
这个错误几乎全是服务端和客户端签名逻辑不一致导致的，极少是密钥错了。
立即学习“PHP免费学习笔记（深入）”；
- 检查是否漏了某个必传参数（比如忘了传
timestamp，但服务端参与了签名计算） - 检查
nonce是否被重复使用，服务端已拒绝该值（可临时关掉 nonce 校验快速验证） - 检查客户端是否对参数值做了额外 URL decode 或 trim，而服务端没做对应处理
- 检查服务端是否误把
$_GET和$_POST混在一起签名——应统一从file_get_contents('php://input')解析 JSON，或明确约定只取$_GET
要不要用 JWT 或 RSA？
简单内部系统或 App 后端，hmac_sha256 + timestamp + nonce 足够。JWT 多一层解析开销，还容易因时钟不同步或算法配置（alg:none）出问题；RSA 签名慢、密钥管理复杂，除非对接银行或政务平台等强合规场景。
- 如果已有 OAuth2 流程，优先复用 access_token 校验，别另搞一套签名
- 如果接口要开放给第三方，建议把签名逻辑封装成 SDK，避免每个调用方自己拼串出错
- 生产环境务必记录失败签名的原始参数（脱敏后），否则排查时只能靠猜
签名本身不难，难的是所有环节——参数选取、排序、编码、传输、缓存、日志——都保持严格一致。少一个 urlencode，就可能卡一上午。
