不能用计算属性名动态匹配多渠道支付网关的异步签名验签逻辑，必须按各渠道文档严格执行参数筛选、字典序排序、utf-8 url编码及指定算法验签，并通过白名单预定义字段列表确保安全合规。
不能用计算属性名动态匹配多渠道支付网关的异步签名验签逻辑。签名验签必须严格按各渠道文档规定的参数列表、排序规则、编码方式和密钥类型执行，不能靠运行时拼接字段名来“猜”哪些参数参与签名。
验签不是读取对象属性，而是还原原始字符串
支付宝、微信等网关在异步通知中发送的是扁平化的 key=value 参数集合（如 out_trade_no=xxx&trade_status=TRADE_SUCCESS&sign=xxx），验签前需：
- 剔除
sign和sign_type字段 - 对剩余所有参数按字典序升序排列（注意：是参数名字符串排序，不是对象键的遍历顺序）
- 拼成
key1=value1&key2=value2格式的待签名串（value 必须 UTF-8 URL 编码） - 用对应私钥和指定算法（如 RSA2）对该字符串验签
多渠道需独立配置验签规则
不同渠道参数名、必填项、编码要求差异大，无法用统一“计算属性名”覆盖：
- 支付宝：参数名全小写（
out_trade_no）、_input_charset必传、notify_type决定参数结构 - 微信：参数名驼峰（
outTradeNo）、要求 XML 解析后转为数组再排序、sign字段本身不参与签名 - 银联：使用 SHA256withRSA，参数含
signature和signMethod，且要求去除空值参数
安全做法是白名单+预定义映射
应在服务端维护每种渠道的验签元数据：
- 声明该渠道参与签名的固定字段名列表（如支付宝：
["app_id","out_trade_no","trade_no","trade_status","total_amount"]） - 指定排序方式（通常为字典序）、编码方式（UTF-8 + urlencode）、签名算法（RSA2/SHA256withRSA）
- 从 HTTP POST body 中解析原始参数，过滤出白名单字段，再构造待验签串
别在前端做验签，也别试图“动态推导”字段
验签必须在可信服务端完成，且字段列表不能由前端传入或运行时反射推断。所谓“计算属性名”容易忽略以下风险：
- 漏掉隐藏字段（如支付宝的
notify_time、微信的nonce_str） - 误包含业务无关字段（如你系统自增的
request_id）导致验签失败 - 排序错误或编码不一致（如未对中文 value 做 urlencode）直接导致签名不匹配
