hash_hmac 是 PHP 生成 HMAC 签名的唯一推荐函数，需用原始数据与保密密钥直接计算，禁用预哈希；验签必须用 hash_equals() 防时序攻击；算法首选 sha256，参数须标准化（如 ksort + http_build_query）。
hash_hmac 是 PHP 生成 HMAC 签名的唯一推荐函数
PHP 不需要“生成 HMAC 密钥”，而是直接用 hash_hmac() 对原始数据 + 已有密钥做签名。所谓“HMAC 密钥”就是你自定义的字符串（如 $secretKey = 'my_api_secret_2026'），它不通过算法生成，也不该公开或推导——它是你和调用方共享的、保密的凭据。
常见误解是以为要像 RSA 那样“生成密钥对”，但 HMAC 是对称认证，只靠一个密钥。只要密钥足够随机、长度足够（建议 ≥32 字节）、不硬编码在前端或日志里，就满足基本安全要求。
- 密钥建议用
random_bytes(32)生成后 Base64 编码存储，避免控制字符问题 - 不要用时间戳、用户名、ID 等可预测值当密钥
- 密钥一旦泄露，整个签名体系即失效，需立即轮换
参数顺序错、数据预哈希是跨语言不一致的主因
JavaScript（CryptoJS）、Python（hmac）、Go（crypto/hmac）都要求：原始消息 + 原始密钥 → 直接进 HMAC。而很多 PHP 开发者会先 hash('sha256', $message)，再把哈希结果喂给 hash_hmac()，这会导致签名完全对不上。
正确做法永远是：原始数据原样传入，不加工、不 encode、不 trim（除非协议明确要求）。比如数组要先 ksort() + http_build_query() 统一序列化格式，但绝不能对结果再 hash 一次。
立即学习“PHP免费学习笔记（深入）”；
使用 JSON Schema 验证 JSON 数据，从示例 JSON 生成 schema，并将其转换为 TypeScript 接口、Python 数据类或 Markdown 文档。
- 错误：
$data = hash('sha256', $raw); hash_hmac('sha256', $data, $key) - 正确：
hash_hmac('sha256', $raw, $key) - 若需兼容 JS/CryptoJS，确保双方使用完全相同的原始字符串（包括空格、换行、编码）
验证签名必须用 hash_equals()，否则存在时序攻击风险
PHP 中用 == 或 === 比较两个签名字符串，攻击者可通过响应时间差异逐步推断出正确签名的每一位，这就是时序攻击。PHP 提供了恒定时间比较函数 hash_equals()，专为此设计。
它要求两个参数都是字符串，且长度相等才开始逐字节比对；若长度不同，会填充到相同长度再比，彻底消除时间侧信道。
- 必须写成：
hash_equals($expectedSign, $receivedSign) - 若
$receivedSign来自 GET/POST，务必先检查是否为字符串、非空、长度合理（如 sha256 固定 64 字符） - 不校验长度直接传入
hash_equals()可能触发警告，建议前置判断
算法选 sha256 足够，别碰 md5/sha1
虽然 hash_hmac() 支持 'md5'、'sha1'、'sha256'、'sha512' 等，但 'md5' 和 'sha1' 已被证实存在碰撞漏洞，NIST 和主流 API（微信、支付宝、Stripe）均已弃用。SHA-256 是当前事实标准：性能好、兼容广、安全性足。
注意：PHP 的 hash_algos() 返回列表里含 'sha256'，无需额外扩展；但某些旧版 CentOS 可能默认禁用部分算法，上线前建议加一行 in_array('sha256', hash_algos()) 校验。
- 别为了“更安全”盲目选
'sha512'：计算开销翻倍，签名长度变长，而实际安全增益微乎其微 - 所有参与签名的字段（含 timestamp、nonce）必须和签名逻辑严格一致，否则哪怕算法对，也会验签失败
ksort() 导致参数顺序不一致，或没过滤 sign 字段导致自己把自己签进去了。这些错误不会报错，只会让签名永远对不上。 
