正确做法是先构造数组、规范化排序拼串生成签名、再将签名字段加入数组统一JSON编码；验签需剔除sign后重走相同流程，关键在数据预处理一致。
PHP 返回 JSON 时怎么加签名
直接在 json_encode() 后拼签名，是常见但错误的做法。签名必须覆盖原始业务数据结构，而不是最终字符串（因为 JSON 序列化顺序、空格、转义等可能变化）。正确做法是：先构造好要返回的数组，再用该数组生成签名，最后把签名字段塞进数组里一起编码。
- 签名算法推荐
hash_hmac('sha256', $data_str, $secret_key)，别用md5()或裸sha1() -
$data_str应该是规范化的键值对字符串，比如按 key 字典序排序后拼成k1=v1&k2=v2，而非直接json_encode($arr) - 务必统一编码（如全部 UTF-8），避免中文被 urlencode 或转义不一致导致验签失败
- 示例关键步骤：
$payload = ['code' => 0, 'data' => ['id' => 123], 'ts' => time()]; ksort($payload); // 确保键顺序 $data_str = http_build_query($payload, '', '&', PHP_QUERY_RFC3986); $sign = hash_hmac('sha256', $data_str, $secret_key); $payload['sign'] = $sign; echo json_encode($payload);
前端或第三方怎么验这个签名
验签不是“拿 response.text() 做一次 hash”，而是重走服务端签名逻辑：解析 JSON → 剔除 sign 字段 → 按同样规则排序拼串 → 再算一次 HMAC → 对比是否相等。任何环节不一致都会失败。
- 必须剔除
sign字段后再参与拼串，否则等于自己验证自己，失去意义 - 注意前端
JSON.parse()后对象属性顺序不保证，不能直接Object.keys(obj)拼 —— 要显式排序，例如：Object.keys(data).sort().map(k => `${k}=${data[k]}`).join('&') - 时间戳
ts字段建议校验（如 ±300 秒），防止重放攻击；服务端也要记录近期已接受的ts防重放 - PHP 服务端验签时，别从
$_POST或file_get_contents('php://input')直接解析 —— 先json_decode(file_get_contents('php://input'), true)，再剔除sign，再拼串
为什么验签总失败？常见坑点
90% 的签名失败不是算法错了，而是数据预处理不一致。最常踩的几个点：
-
http_build_query()默认对 value 做urlencode()，而你手动拼串时忘了 —— 导致前后编码不一致 - PHP 数组中整数 key（如
[0 => 'a', 1 => 'b']）经ksort()后顺序不变，但 JSON 编码后 key 是字符串"0"，前端解析后可能丢失顺序 - 传了
null或空数组，http_build_query()会跳过它们，但前端 JS 拼串时可能保留k=null或k=，造成差异 - 密钥用了 base64 编码过的字符串，但没在两端统一 decode；或者密钥含不可见字符（如 Windows 换行符）
- 响应头没设
Content-Type: application/json; charset=utf-8，某些客户端解析时默认 ISO-8859-1，中文变乱码再签名就崩了
要不要用 JWT 替代手写签名
如果只是简单接口防篡改，手写签名够用且轻量；但一旦涉及用户身份、过期、刷新、多级权限，JWT 就更合适 —— 它把签名、载荷、头部、算法全标准化了，有成熟库（如 firebase/php-jwt）可直接用。
立即学习“PHP免费学习笔记（深入）”；
- JWT 的
signature本质也是 HMAC 或 RSA，但它强制要求载荷（payload）是 JSON 字符串 + Base64Url 编码，消除了拼串歧义 - 不要自己实现 JWT 签名逻辑，直接用经过审计的库；也不要硬编码
alg: none或用弱密钥 - 注意：JWT 默认不加密 payload，敏感字段（如手机号）不能明文放
payload里 - 如果已有签名体系且稳定运行，没必要强行换成 JWT —— 复杂度和收益不匹配
