目前证据链已经足够强，可以把问题基本定性为： uniCloud 阿里云 URL 化云函数 的最终 HTTP 响应形态， 大概率不满足微信消息推送 Token 校验所要求的“原样纯文本 echostr”

最终结论

• 目前证据链已经足够强，可以把问题基本定性为： uniCloud 阿里云 URL 化云函数 的最终 HTTP 响应形态， 大概率不满足微信消息推送 Token 校验所要求的“原样纯文本 echostr”

• 这次你提供的 wxPay 运行日志已经证明： 微信校验请求确实到达了当前云函数

• 我重新复算后也证明：在 Token=111111 这次请求里， 签名完全正确

• 因此，当前问题的主矛盾已经 不是 签名算法、不是时区、也不是微信没有打到函数，而是 函数出口响应是否被 URL 化网关包装
  证据链

• 请求命中云函数：

  • 本次 wxPay 日志明确显示收到 GET /
  • queryStringParameters 中包含 signature / echostr / timestamp / nonce
  • 来源 IP 也符合微信服务器访问场景

• 签名数学验证通过：

  • 本次参数为：
  • token = 111111
  • timestamp = 1781968484
  • nonce = 314367462
  • signature = fa49837ba09da417f661befadc2d20346439c8bd
  • 按微信规则排序并拼接后得到：
  • 1111111781968484314367462
  • 计算 sha1 结果：
  • fa49837ba09da417f661befadc2d20346439c8bd
  • 与日志中的 signature 完全一致

• 浏览器访问 URL 的异常现象：

  • 浏览器和手机浏览器访问同一 URL 时，不是显示纯文本，而是下载了 wxPay.json
  • 下载内容是类似下面的 JSON 包装结构，而不是裸文本：

• 这说明至少在某些请求路径上， uniCloud 网关会把函数返回对象包装成 JSON 文件响应，而不是直接透传 HTTP body
  排除项

• 不是时区问题：

  • 微信 Token 校验依赖的是 token + timestamp + nonce 的排序后 sha1
  • 它不要求服务器与微信做“北京时间对齐”
  • timestamp 是参与签名的字符串，不是拿来做本地时区换算判断

• 不是签名公式错误：

  • 这次日志已用真实参数复算成功

• 不是“请求没到函数”：

  • 本次日志已证明请求命中 wxPay

• 不是“明文模式/JSON 模式理解错了”：

  • 这两项影响的是后续消息体处理方式
  • GET Token 校验 本质上仍要求服务端正确返回 echostr
    最可能的根因

• 根因候选 1：

  • 云函数内部即便已经返回了：

• 但 uniCloud 阿里云 URL 化网关 仍可能把它再次包装成 JSON 结构返回给客户端

• 根因候选 2：

  • 云端实际读取到的 WECHAT_MESSAGE_TOKEN 仍有环境不一致问题
  • 例如旧环境值、空格、换行、未重新运行、多个环境混用

• 但从当前证据强弱看：

  • 响应格式问题 的优先级 高于 token 读取错误
    当前技术判断

• 如果你在代码里再怎么微调 sha1 算法、排序逻辑、时区逻辑， 大概率都不会解决问题

• 如果日志能进一步证明程序已经进入“验签成功分支”，但微信后台仍失败，那就几乎可以正式定性为：

  • 阿里云 uniCloud URL 化云函数 这条接入路径 不适合作为微信消息推送服务器地址
  • 或者至少当前网关层 不支持 微信要求的裸文本握手响应
    建议的验证顺序

• 第 1 步：加最小日志验证“是否进入成功分支”

  • 记录收到的 signature
  • 记录本地计算的 expectedSignature
  • 记录比较结果 matched=true/false
  • 记录是否准备返回 echostr

• 第 2 步：如果确认进入成功分支，但微信仍失败

  • 直接停止继续折腾业务代码
  • 改为提交 DCloud/uniCloud 工单

• 第 3 步：工单若确认阿里云 URL 化不支持原样文本返回

  • 就不要再在这个入口上耗时间
  • 直接切换承接消息推送的入口形态
    建议的决策方案

• 方案 A：继续用当前 阿里云 URL 化

  • 风险：很可能继续卡在网关输出格式
  • 适合：官方明确给出“可返回裸文本”的正确写法后再试

• 方案 B：切到 微信云托管 / 腾讯云可控 HTTP 入口

  • 优点：更接近微信官方预期的标准 HTTP 服务
  • 适合：你要尽快通过消息推送校验

• 方案 C：单独做一个极简中转 HTTP 服务

  • 只负责 GET echostr 和 POST 推送
  • 业务再转发到现有后端
  • 适合：当前主业务不想大改，但必须马上解决接入问题
    对你现在最实用的结论

• 你现在已经可以非常有把握地对外说明：

  • wxPay 已收到微信 GET 校验请求
  • Token=111111 这一轮签名验算完全正确
  • 失败原因已不再指向签名算法
  • 最大嫌疑是 uniCloud 阿里云 URL 化 对响应做了 JSON 包装，导致微信拿不到“纯文本 echostr”
    可直接提交的结论话术

• 经真实日志与签名复算确认，微信服务器发起的 GET 校验请求已成功到达当前 uniCloud 阿里云 URL 化云函数，且在 Token=111111 的测试中，signature 与按微信官方规则计算出的 sha1 值完全一致。因此问题基本可排除为签名算法、时间对齐或请求未到达。当前最高概率根因是 uniCloud 阿里云 URL 化网关对云函数返回结果进行了 JSON 包装，未能按微信要求向外返回原样纯文本 echostr，导致 Token 校验失败。