Webhook签名用于验证消息来源和完整性，但接收端必须按官方算法、秘密值和原始请求体实际校验。只看到签名请求头，或在日志里记录它，并不等于完成认证；重试和重放也需要独立管理。
确认是哪一种Webhook
WooCommerce自身发出的Webhook与支付网关回调可能使用不同签名规则，不能混用头名和算法。记录发送方、主题、目标和配置秘密，秘密只保存于受控系统。不要以请求声称来自WooCommerce或IP看起来熟悉作为唯一信任依据。
保留用于校验的原始请求体
某些接收框架会先解析和重组JSON，导致用重组后的文本计算结果与发送原文不同。按当前官方说明获取原始字节、计算并安全比较签名，校验失败时不继续执行业务。排错可记录必要标识，不公开秘密或完整客户数据。
将认证和业务授权分开
签名正确说明请求通过约定认证，不代表任何消息都可改变任意订单。仍要核对主题、对象、店铺及允许操作，避免跨环境或错误目标。需要防重放和去重时使用明确事件关联，不能把签名当作一次性票据自动解决所有重复问题。
测试有效与错误样本
在授权环境使用正常签名、错误秘密、改变内容及缺失头部等样本，确认接收端按预期拒绝。再检查轮换秘密与重试期间的兼容安排，避免切换后全部消息失败。成功结果应能对应一条真实处理记录，而非只看HTTP200。
关键区别
签名头：携带校验信息；存在不等于已验证。
原始请求体：计算完整性的输入；解析重组可能改变字节。
业务判断：决定允许的操作；签名不能替代去重授权。
怎样确认处理到位
有效请求可处理，缺失或错误签名被拒绝，跨环境与重复消息按规则处理，秘密和客户资料不泄露，轮换与失败监测有明确安排。
容易误判的边界
本文不展示真实店铺密钥或可用于攻击的凭据。支付服务的签名机制应读其自身官方文档，不能照搬WooCommerce发出Webhook的规则。
