单纯用 hidden 字段防篡改无效，因用户可轻易修改其值；应使用 hmac 签名机制在服务端校验数据完整性，配合严格顺序拼接、hash_equals 安全比对及业务层权限检查。
为什么单纯用 hidden 字段防篡改根本无效
很多人把关键参数（比如 price=99.9、user_id=123）塞进 <input type="hidden">，以为用户看不到就安全了。其实只要打开浏览器开发者工具，瞬间就能改掉这些值再提交。服务器端不做校验，等于把控制权直接交给了客户端。
真正可行的思路是：不阻止用户修改，而是让服务器能立刻识别出“这个数据被动过手脚”。HMAC 就是干这事的——它不是加密，而是生成一段不可伪造的签名，和原始数据绑定在一起。
PHP 里用 hash_hmac() 生成和验证签名的最小闭环
核心就两步：提交前生成签名，接收后重新计算并比对。密钥必须严格保密，绝不能写在前端或日志里。
- 生成签名时，把所有需要保护的字段按固定顺序拼成字符串（例如
"user_id=123&amount=99.9&product_id=456"），再用hash_hmac('sha256', $data, $secret_key) - 表单里额外加一个隐藏字段：
<input type="hidden" name="hmac" value="生成的签名"> - 服务端收到请求后，用同样逻辑拼接参数、调用
hash_hmac()，再用hash_equals()安全比对（防止时序攻击）
示例片段：
立即学习“PHP免费学习笔记（深入）”；
// 签名生成（提交前）
$payload = http_build_query([
'user_id' => $_SESSION['id'],
'amount' => $order->amount,
'product_id' => $product->id
]);
$hmac = hash_hmac('sha256', $payload, $_ENV['HMAC_SECRET']);
// 验证（接收后）
$received_payload = http_build_query(array_filter($_POST, function($k) {
return $k !== 'hmac';
}, ARRAY_FILTER_USE_KEY));
if (!hash_equals($hmac, $_POST['hmac'] ?? '')) {
die('数据已被篡改');
}
常见踩坑点：顺序、编码、空值处理
签名失效往往不是算法问题，而是数据没对齐。哪怕字段顺序差一位、URL 编码多一层、空字符串和 null 混用，都会导致前后签名不一致。
- 务必统一使用
http_build_query()拼接，不要手拼字符串——它会自动处理键值排序、URL 编码和空值跳过 - 所有参与签名的字段必须明确约定是否包含（比如
token或timestamp），漏一个就验不过 - 如果前端用了 JSON 提交，后端解析后要确保数组键顺序和原始 JSON 一致；更稳妥的做法是先
json_encode($data, JSON_UNESCAPED_UNICODE | JSON_SORT_KEYS) -
hash_equals()必须用，直接用===有被时序攻击绕过的风险
签名只是完整性校验，不能替代权限检查
HMAC 能确认“数据从发出到接收没被改”，但不能保证“这个人有权提交这笔订单”。比如用户 A 篡改了 user_id=2 再提交，签名可能依然有效——因为他用自己的密钥签的，只是你没校验当前登录人和表单里的 user_id 是否一致。
所以真实场景中，必须叠加业务层校验：
- 签名通过后，立刻查数据库确认
$_POST['user_id']确实属于当前登录会话 - 金额类字段要二次比对商品库里的价格，不能只信表单传来的
amount - 敏感操作（如删除、转账）建议加时间戳 + 过期机制，签名超过 5 分钟自动作废
最危险的错觉，就是以为加了 HMAC 就万事大吉。它只解决“有没有被改”，不解决“该不该这么改”。
