企业官网建设流程全解析

1. 为什么微信支付的三种方式不能混着用——从商户后台第一眼就该看清的底层逻辑

你刚接手一个新项目，技术负责人甩过来一句话：“微信支付接入一下，H5和JSAPI都得支持。”你打开微信支付商户平台，看到“JSAPI支付”“H5支付”“Native支付”三个入口，点进去全是密密麻麻的参数、回调地址、签名规则……更糟的是，测试环境里用户在iOS微信里能付，在安卓微信里跳转失败；H5页面在浏览器里能唤起支付，在微信内置浏览器里却提示“不支持当前环境”。这时候你才意识到：不是微信支付不好用，而是你根本没搞懂这三种方式各自存在的物理边界。

这三种支付方式，本质不是“功能选项”，而是微信支付为不同运行容器（Runtime Context）和用户触达路径量身定制的三套独立协议栈。JSAPI不是“JS版API”，H5不是“网页版支付”，Native也不是“原生App专用”——这些叫法全是历史遗留的误导性简称。真实情况是：

• JSAPI支付：专为微信内嵌浏览器（即微信WebView）设计，依赖微信JS-SDK注入的wx.chooseWXPay全局方法，其调用前提是用户已通过wx.config完成当前页面的JS权限校验，且必须运行在微信客户端v6.5.7+环境中。它不走标准HTTP跳转，而是由微信客户端直接接管支付流程，因此无法在Safari、Chrome或任何非微信浏览器中执行。

• H5支付：专为外部浏览器（如手机自带浏览器、QQ浏览器、UC等）设计，核心动作是后端统一下单后返回一个mweb_url，前端重定向至此URL，由微信支付网关在外部浏览器中渲染一个中间页，再唤起微信App完成支付。它的存在意义，就是解决“用户没装微信App但想用微信支付”的场景——比如用户在淘宝APP内点击商品，跳转到商家H5页，此时若用户已安装微信App，H5支付可无缝唤起；若未安装，则降级为二维码支付。

• Native支付：专为原生App（iOS/Android）设计，不依赖任何Web容器，由App SDK直接调用微信支付SDK完成预下单、拉起支付、结果回调全流程。它的关键特征是支付请求由App自身发起，而非网页JavaScript，因此天然规避了跨域、WebView限制、JS注入失败等Web侧问题。你看到的“扫码支付”“被扫支付”只是Native支付的两种业务形态，底层共用同一套API。

提示：很多团队踩的第一个坑，就是把JSAPI的appId、timeStamp、nonceStr、package、signType、paySign六元组，直接硬编码进H5页面，然后在Chrome里调试——这注定失败。因为paySign的生成依赖jsapi_ticket，而jsapi_ticket只能通过微信服务器获取，且必须绑定当前域名白名单。你在本地localhost调试时，连wx.config都初始化失败，更别说生成有效签名。

我去年帮一家连锁药店做小程序+公众号H5双渠道支付重构，他们原来的方案是：公众号菜单跳转H5页，H5页里同时集成JSAPI和H5支付逻辑，用WeixinJSBridge检测环境，能调JSAPI就调，不能就fallback到H5支付。结果上线后投诉率飙升——原因很简单：微信iOS版对WeixinJSBridge的调用有严格沙箱限制，某些版本下WeixinJSBridge.invoke('getNetworkType')会静默失败，导致H5支付逻辑永远不触发。最后我们砍掉所有环境探测，改为服务端根据User-Agent精确识别终端类型，主动下发对应支付方式的参数，投诉率直接归零。

这背后反映的是一个铁律：微信支付的三种方式，不是“前端适配策略”，而是服务端路由决策。你的后端API必须在统一下单接口（unifiedorder）中，根据trade_type参数明确指定支付类型，并严格校验调用方身份——JSAPI要求openid（用户在公众号/小程序的唯一标识），H5支付要求scene_info（含h5_info.bill_type和h5_info.bill_no），Native支付则要求spbill_create_ip（必须是真实公网IP，不能是内网或127.0.0.1）。漏掉任何一个字段，微信服务器就会返回INVALID_REQUEST或PARAM_ERROR，而错误码说明文档里往往只写“参数错误”，根本不会告诉你缺了哪个。

所以别再纠结“前端怎么判断环境”，真正该花时间的地方，是理清你的业务场景到底属于哪一类容器：用户是从微信聊天窗口点击链接进来？还是从短信链接点击进来？还是从自家App内WebView打开？这三类场景，分别对应JSAPI、H5、Native，没有模糊地带。接下来，我们就一层层拆开这三套协议的真实数据流。

2. JSAPI支付：微信内闭环生态下的“免跳转”支付链路全解析

JSAPI支付之所以被称作“最丝滑”的微信支付方式，是因为它实现了零页面跳转、零用户感知的支付唤起。但这种丝滑感，是以极高的环境约束为代价换来的。它的完整链路不是简单的“前端调API→用户确认→支付成功”，而是一条横跨微信客户端、商户服务器、微信支付网关三方的精密协同流水线。我们以一个典型电商下单场景为例，还原每一步的真实数据交互与关键校验点。

2.1 第一阶段：页面初始化——wx.config不是摆设，而是安全门禁

用户点击公众号菜单进入商品详情页，浏览器加载HTML。此时第一步不是调支付，而是让微信客户端确认“这个页面有权使用微信JS接口”。这通过wx.config完成，其参数必须由商户后端生成：

// 前端调用（伪代码） wx.config({ debug: false, appId: 'wx1234567890abcdef', timestamp: 1712345678, nonceStr: 'aBcDeFgHiJkLmNoPqRsTuVwXyZ', signature: 'xxxxxx', // 关键！由后端计算 jsApiList: ['chooseWXPay'] });

这个signature的生成，是JSAPI支付的第一道生死线。它不是对上述参数简单拼接MD5，而是遵循微信官方规定的SHA1签名算法，且必须包含以下要素：

1. jsapi_ticket：不是access_token，而是微信JS-SDK专用票据，有效期2小时，需缓存并自动刷新。获取路径：https://api.weixin.qq.com/cgi-bin/ticket/getticket?access_token=ACCESS_TOKEN&type=jsapi
2. noncestr：随机字符串，长度32位以内，建议用UUIDv4生成
3. timestamp：当前时间戳（秒级，非毫秒）
4. url：当前页面的完整URL（含query参数，不含hash），且必须与商户平台配置的JS接口安全域名完全一致（注意：https://shop.example.com/goods?id=123≠https://shop.example.com/goods?id=123&ref=weixin）

签名字符串拼接规则为：jsapi_ticket=xxx&noncestr=yyy&timestamp=zzz&url=aaa，然后对整个字符串做SHA1哈希。很多人在这里栽跟头——把url写成window.location.href，结果带上了#section1锚点，或者漏掉了query参数中的特殊字符（如&未编码），导致签名永远不匹配。

注意：wx.config失败时，wx.ready回调永远不会触发，后续所有JSAPI调用均无效。但微信开发者工具里debug:true会弹出详细错误，而真机上只会静默失败。我的经验是：在wx.error回调里打印res对象，重点关注errMsg字段，常见错误如config:invalid signature（签名错）、config:invalid url domain（域名未备案）、config:permission denied（JS接口未开通）。

2.2 第二阶段：统一下单——后端必须扛起全部责任

当用户点击“立即支付”，前端调用wx.chooseWXPay前，必须先向商户后端发起统一下单请求。这里的关键是：JSAPI支付的下单参数，与H5/Native完全不同。商户后端调用微信支付统一下单API（https://api.mch.weixin.qq.com/pay/unifiedorder）时，必须传入：

特别注意openid的获取方式。如果你的H5页面运行在公众号内，openid可通过OAuth2.0网页授权获取（snsapi_base即可，无需用户信息）；如果运行在小程序WebView里，则需通过wx.miniProgram.getEnv判断环境，再调用小程序API获取。绝对禁止在JSAPI支付中传入H5支付所需的scene_info字段，否则微信服务器会直接拒单。

我曾遇到一个诡异问题：同一套下单代码，在测试环境总返回FAIL，错误信息是{"err_code":"INVALID_REQUEST","err_code_des":"参数错误"}。排查三天才发现，测试环境的Nginx反向代理配置了proxy_set_header X-Real-IP $remote_addr;，但后端Java代码里读取IP时用了request.getRemoteAddr()，拿到的是Nginx内网IP（10.x.x.x），而微信支付要求spbill_create_ip必须是公网IP。解决方案是在Nginx里加proxy_set_header X-Forwarded-For $remote_addr;，后端改用request.getHeader("X-Forwarded-For")读取。

2.3 第三阶段：支付唤起——六元组不是前端拼的，而是后端算的

统一下单成功后，微信支付网关返回prepay_id（预支付交易会话标识）。此时商户后端需用此prepay_id，结合微信支付密钥，生成paySign——这才是前端wx.chooseWXPay真正需要的签名。生成逻辑如下：

1. 构造待签名字符串：appId=xxx&nonceStr=yyy&package=prepay_id=zzz&signType=MD5&timeStamp=aaa&key=bbb
2. 对字符串做MD5哈希（注意：key放在末尾，且不参与URL编码）
3. 转为大写十六进制字符串

前端收到的六元组必须严格按此格式传递：

wx.chooseWXPay({ timestamp: 1712345678, // 注意：此处是秒级时间戳，与wx.config的timestamp无关 nonceStr: 'aBcDeFgHiJkLmNoPqRsTuVwXyZ', package: 'prepay_id=wx1234567890abcdef1234567890abcdef', signType: 'MD5', paySign: 'A1B2C3D4E5F6G7H8I9J0K1L2M3N4O5P6' // 后端生成，前端只负责传入 });

这里有个致命陷阱：package字段的值必须是prepay_id=xxx，不能多一个空格，不能少一个等号，不能有任何URL编码。我见过最离谱的案例：后端用URLEncoder.encode(prepayId, "UTF-8")对prepay_id做了编码，结果前端传给微信的package变成prepay_id%3Dwx123...，微信客户端解析失败，直接黑屏。

2.4 第四阶段：结果回调——别信前端，只信微信服务器的POST通知

用户完成支付后，微信客户端会触发success或fail回调。但这些回调仅作前端用户体验优化，绝不能作为支付成功的依据。真实支付结果，必须依赖微信支付服务器向商户后台notify_url发送的异步通知。

该通知是HTTP POST请求，Content-Type: application/xml，Body为XML格式。关键点在于：

• 必须验签：微信会在XML中附带sign字段，其值是对除sign外所有字段按字典序拼接后，用API密钥MD5得到。验签失败必须返回<xml><return_code><![CDATA[FAIL]]></return_code><return_msg><![CDATA[签名失败]]></return_msg></xml>，否则微信会持续重发。
• 必须校验result_code和return_code：两者都必须为SUCCESS才算真正成功。
• 必须校验out_trade_no：防止重复通知。
• 必须校验total_fee与订单金额是否一致：避免金额被篡改。

我处理过一个线上事故：某次大促期间，notify_url接口因数据库连接池耗尽，响应超时（>5秒），微信服务器判定通知失败，开始每分钟重发一次，持续24小时。结果订单系统收到1440次重复通知，若没做幂等处理（如用Redis记录out_trade_no已处理），就会导致库存扣减1440次。解决方案是：在通知处理开头，用SETNX指令尝试获取分布式锁，锁住out_trade_no，超时时间设为30秒，确保同一订单只被处理一次。

JSAPI支付的终极价值，在于它把支付流程完全封装在微信生态内，用户无需离开当前页面，也无需理解“跳转到微信App”这个概念。但这份便利的背后，是商户必须对微信的每个校验环节都做到毫米级精准。它不是“前端技术”，而是“微信生态合规工程”。

3. H5支付：外部浏览器里的“微信支付体验”如何实现——从URL跳转到支付完成的全链路

当你在淘宝APP里点开一个第三方店铺的商品页，页面底部出现“微信支付”按钮，点击后跳转到一个微信风格的中间页，再唤起微信App完成支付——这就是H5支付的典型场景。它的设计哲学很清晰：在非微信环境下，复刻微信支付的用户体验。但要实现这一点，必须绕过微信客户端的JSAPI限制，转而依赖HTTP重定向和微信支付网关的中间页渲染能力。这条链路看似简单，实则暗藏多个极易被忽略的细节。

3.1 核心前提：H5支付不是“网页调微信”，而是“网页跳微信网关”

很多开发者误以为H5支付是前端JavaScript调用某个API，其实完全相反：H5支付的整个支付流程，由HTTP 302重定向驱动。商户后端调用统一下单API后，微信支付网关返回一个mweb_url，前端只需window.location.href = mweb_url，剩下的事全部交给微信服务器。

这个mweb_url长这样：

https://wx.tenpay.com/cgi-bin/mmpayweb-bin/checkmweb?prepay_id=wx1234567890abcdef1234567890abcdef&package=38271234567890123456789012345678&redirect_url=https%3A%2F%2Fshop.example.com%2Fpay%2Fcallback

其中redirect_url是关键——它定义了用户支付完成后，微信网关将用户重定向回哪里。但这里有个巨大误区：很多人把redirect_url设为自己的支付成功页（如/pay/success?order_id=123），结果发现支付完成后页面一片空白。原因在于：redirect_url接收的不是GET参数，而是微信网关的POST通知。

提示：H5支付的redirect_url必须是一个能接收POST请求的接口，且该接口必须返回HTTP 200状态码。微信网关会向此URL POST一个XML格式的通知，内容与JSAPI支付的notify_url完全相同（含out_trade_no、result_code等字段）。你不能把它当成普通跳转链接来用。

3.2 统一下单的特殊要求：scene_info字段是H5支付的身份证

H5支付的统一下单请求，与JSAPI支付最大的区别在于trade_type和scene_info字段：

scene_info字段的JSON结构必须严格符合规范：

• h5_info.type：固定为WAP，表示Web App
• h5_info.wap_url：用户支付完成后，微信网关将重定向至此URL（即上面说的redirect_url的父路径）
• h5_info.wap_name：在微信中间页上显示的网站名称，20个字符内，建议用品牌名

这个字段的作用，是让微信支付网关知道“这个H5页面属于谁”，从而在中间页展示正确的品牌信息，并控制重定向行为。如果wap_url与redirect_url的域名不一致，微信网关会拒绝跳转，返回INVALID_REQUEST错误。

我曾帮一家教育机构接入H5支付，他们把wap_url设为https://edu.example.com，而redirect_url设为https://pay.edu.example.com/callback，结果用户支付完成后卡在中间页，提示“网络错误”。排查发现，微信网关要求redirect_url的域名必须是wap_url的子域名或完全一致。解决方案是把redirect_url改为https://edu.example.com/pay/callback，问题立刻解决。

3.3 支付中间页的三大隐藏行为：你看到的不只是跳转

当用户访问mweb_url时，微信支付网关会渲染一个中间页。这个页面的行为，远比表面看到的复杂：

1. 自动唤起微信App：如果用户手机已安装微信App，中间页会自动尝试唤起微信（通过intent://或weixin://协议），用户无需点击“打开微信”按钮。这是H5支付体验优于传统跳转的核心。
2. 降级为二维码：如果用户未安装微信App，中间页会动态生成一个支付二维码，用户可用其他设备扫码完成支付。二维码的有效期为2小时。
3. 超时自动关闭：如果用户在中间页停留超过15分钟未操作，页面会自动关闭并返回redirect_url，此时redirect_url收到的POST通知中result_code为FAIL，err_code为PAYERROR。

这三个行为，都是微信网关在服务端完成的，前端无法干预。但你可以通过mweb_url中的redirect_url参数，控制用户最终回到哪里。例如，你可以在redirect_url里带上订单ID，这样用户无论支付成功或失败，都能回到对应的订单详情页。

3.4 移动端适配的致命陷阱：iOS微信内H5支付的“假死”现象

H5支付在iOS微信客户端内有一个著名Bug：当用户从微信聊天窗口点击H5链接进入页面，页面内调用window.location.href = mweb_url后，微信会弹出“即将离开微信，是否继续？”的提示框。用户点击“继续”后，页面白屏，再也无法唤起微信App。

根本原因在于：iOS微信的WKWebView对window.location.href跳转有严格限制，尤其是跳转到微信自有域名（wx.tenpay.com）时，会触发安全拦截。解决方案只有一个：改用<a>标签模拟跳转。

<!-- 错误做法 --> <script> document.getElementById('payBtn').onclick = function() { window.location.href = 'https://wx.tenpay.com/...'; }; </script> <!-- 正确做法 --> <a id="h5PayLink" href="https://wx.tenpay.com/..." style="display:none;"></a> <script> document.getElementById('payBtn').onclick = function() { document.getElementById('h5PayLink').click(); }; </script>

原理是：<a>标签的click()事件被iOS微信视为用户主动触发，不受WKWebView的跳转限制。而window.location.href赋值被视为脚本自动跳转，被拦截。这个技巧在2023年iOS微信v8.0.45之后依然有效，是我在线上环境反复验证过的。

H5支付的价值，在于它打破了微信生态的围墙，让微信支付能力可以延伸到任何浏览器环境。但它不是“万能钥匙”，而是“条件反射式”的支付通道——你必须精确满足微信网关的所有前置条件，它才会为你打开那扇门。

4. Native支付：原生App里的“无感支付”如何落地——扫码与被扫的本质统一

Native支付常被误解为“只有App才能用”，其实它的本质是脱离Web容器的、由原生代码直接驱动的支付协议。无论是你家楼下超市的扫码枪扫你手机上的付款码，还是你用美团APP点外卖时右上角弹出的微信支付弹窗，背后都是Native支付在工作。它的优势在于彻底摆脱了WebView的兼容性问题、JS注入失败风险、跨域限制等Web侧顽疾，但代价是开发成本更高，且必须为iOS和Android分别集成SDK。

4.1 Native支付的两种形态：扫码支付（模式一）与被扫支付（模式二）

Native支付在微信支付文档中分为两种模式，但它们共享同一套API体系，区别仅在于支付请求的发起方不同：

• 模式一（扫码支付）：商户系统生成一个支付二维码，用户打开微信“扫一扫”扫描该码，微信客户端解析后发起支付。典型场景：餐厅桌牌、便利店收银台、共享单车。
• 模式二（被扫支付）：用户在微信内打开“收付款”页面，出示付款码，商户用扫码设备扫描该码，商户系统拿到auth_code后调用统一下单API完成支付。典型场景：地铁闸机、医院挂号、菜市场摊贩。

这两种模式的共同点是：支付请求均由商户系统（而非用户手机）发起。这意味着商户必须有自己的服务器，能调用微信支付API，且能安全存储API密钥。你无法在纯前端H5页面里实现Native支付——因为auth_code（被扫）或code_url（扫码）的生成，必须经过商户服务器与微信支付网关的密钥协商。

4.2 扫码支付（模式一）：从生成二维码到用户扫码的完整闭环

扫码支付的流程，是Native支付中最直观的一种。我们以一个自助咖啡机为例：

1. 用户选择商品：咖啡机屏幕显示“美式咖啡 18元”，用户点击确认。
2. 咖啡机发起统一下单：咖啡机内置的Linux系统（或联网的MCU）调用unifiedorderAPI，trade_type=SCAN，body=美式咖啡，out_trade_no=COFFEE20240405123456，total_fee=1800。
3. 微信返回code_url：API成功响应中包含code_url字段，值为weixin://wxpay/bizpayurl?pr=AbcDef123。
4. 咖啡机渲染二维码：将code_url用QR Code库（如qrcode.js）生成图片，显示在屏幕上。
5. 用户扫码：用户打开微信“扫一扫”，对准屏幕上的二维码，微信客户端解析weixin://协议，自动唤起支付界面。
6. 支付结果通知：用户确认支付后，微信服务器向咖啡机的notify_url发送POST通知，咖啡机收到后启动出杯电机。

这里的关键是code_url的生成。它不是一个普通URL，而是微信定义的自定义协议URI。pr=后面的字符串是微信支付网关生成的预支付凭证，有效期2小时。咖啡机无需理解其含义，只需原样渲染为二维码即可。

注意：code_url必须用标准QR Code格式（Version 2，Error Correction Level M），否则部分老旧扫码枪无法识别。我测试过，用qrcode-generator库生成的二维码，在华为Mate 20的扫码枪上识别率99%，但在某些国产POS机上只有70%。解决方案是：生成二维码后，用zxing库在服务端做一次解码验证，确保code_url能被正确还原。

4.3 被扫支付（模式二）：商户扫码枪如何安全获取用户付款码

被扫支付的难点不在技术，而在用户隐私与风控。用户在微信“收付款”页面出示的付款码，每分钟刷新一次，且包含设备指纹信息。商户扫码枪扫到的auth_code，是一个6位数字+22位字母数字组合（如123456abcd1234567890efgh），它本身不包含金额，只是一个临时授权凭证。

商户系统拿到auth_code后，必须立即调用统一下单API（trade_type=AUTH_CODE），并传入：

• auth_code：扫码枪读取的28位字符串
• body：商品描述
• out_trade_no：商户订单号
• total_fee：订单金额（单位：分）

微信支付网关会实时校验auth_code的有效性（是否过期、是否已被使用、是否来自合法设备），并冻结对应用户的账户余额。如果校验通过，返回prepay_id，商户系统再调用payAPI完成支付。

这里有个严重安全风险：auth_code一旦泄露，攻击者可在1分钟内盗刷用户账户。因此，商户系统必须确保auth_code只在内存中短暂存在，绝不写入日志、数据库或网络传输明文。最佳实践是：扫码枪通过USB串口将auth_code直接传给商户服务器进程，服务器收到后立即调用API，API响应后立即将auth_code变量置为null。

我曾审计过一家连锁超市的收银系统，发现他们的日志文件里明文记录了auth_code，且日志文件权限为644（所有人可读）。这意味着任何能访问服务器的员工，都可以用这些auth_code在测试环境模拟支付。整改方案是：在日志框架中增加敏感字段过滤器，对auth_code、openid、key等字段自动脱敏为***。

4.4 App内集成：React Native与Flutter如何安全调用Native支付

当你的业务跑在React Native或Flutter这样的跨平台框架中时，“Native支付”意味着你必须桥接原生模块。以React Native为例：

• iOS端：需集成WechatOpenSDK，调用[WXApi sendReq:req]发起支付。req对象包含partnerId（商户号）、prepayId（预支付ID）、nonceStr、timeStamp、package、sign等字段，全部由商户后端生成并下发。
• Android端：需集成com.tencent.mm.opensdk，调用IWXAPI.sendReq(req)，参数结构与iOS一致。

关键点在于：签名计算必须在服务端完成。因为sign的生成依赖API密钥，而密钥绝不能硬编码在前端代码中（会被反编译提取）。正确流程是：

1. RN前端调用自己封装的wxPay({orderId: '123'})方法
2. 该方法向商户后端发起/api/wx/prepay请求，传入订单ID
3. 后端查询订单，调用unifiedorderAPI获取prepay_id
4. 后端用prepay_id+ API密钥生成sign，连同其他参数一起返回给RN前端
5. RN前端将参数透传给原生模块，由原生代码调用微信SDK

Flutter同理，需用platform_channel与iOS/Android原生代码通信。切记：任何试图在Dart或JS层计算sign的做法，都是重大安全隐患。

Native支付的终极价值，在于它把支付能力下沉到了操作系统层面，让用户感觉“支付就是点一下的事”。但这份“无感”，建立在商户对微信支付协议的深度理解和对原生开发的扎实功底之上。它不是“选一种支付方式”，而是“选择一种与微信支付网关直连的通信范式”。

5. 三种方式的交叉场景与避坑指南：当用户环境模糊时，如何做出最优决策

现实业务中，用户从来不会按教科书的方式访问你的页面。他可能在微信里点击链接，也可能在短信里点击链接；可能用iPhone，也可能用安卓；可能微信版本很老，也可能刚升级到最新版。当“JSAPI、H5、Native”的边界变得模糊时，如何设计一套鲁棒的支付路由策略？这是我过去三年在多个高并发项目中沉淀下来的实战经验。

5.1 环境识别的黄金法则：User-Agent + Referer + Cookie三位一体

单纯依赖前端JavaScript检测（如WeixinJSBridge、navigator.userAgent.indexOf('MicroMessenger')）是危险的。因为：

• iOS微信v8.0.30+移除了WeixinJSBridge全局对象
• Android微信对userAgent做了伪装，MicroMessenger字符串可能被隐藏
• 用户可能禁用JavaScript

真正的环境识别，必须由服务端主导，综合以下三个HTTP Header：

我的标准做法是：在用户首次访问时，后端生成一个临时session_id，存入Redis，TTL设为30分钟。同时，如果检测到微信环境，立即发起OAuth2.0静默授权（snsapi_base），获取openid并存入该session_id对应的Hash中。后续所有支付请求，都携带此session_id，后端据此判断用户身份和环境。

例如，一个请求的Header如下：

User-Agent: Mozilla/5.0 (iPhone; CPU iPhone OS 16_4 like Mac OS X) AppleWebKit/605.1.15 (KHTML, like Gecko) Mobile/15E148 MicroMessenger/8.0.45(0x18002d2d) NetType/WIFI Language/zh_CN Referer: https://mp.weixin.qq.com/ Cookie: session_id=abc123; wx_openid=oAbc1234567890xyz

后端逻辑：

• 若Referer以mp.weixin.qq.com开头，且Cookie中有wx_openid→JSAPI支付
• 若Referer为空或非微信域名，且User-Agent含MicroMessenger→H5支付
• 若User-Agent含Mobile但不含MicroMessenger（如短信链接）→H5支付
• 若请求来自App内WebView，且User-Agent含MyApp/1.0.0→Native支付

这套逻辑覆盖了99%的线上场景。剩下1%的异常，比如用户清除了Cookie但仍在微信内，我们会fallback到JSAPI支付，并在wx.config失败时，前端自动重试H5支付。

5.2 支付失败的优雅降级：从JSAPI到H5的平滑过渡

用户点击支付按钮后，理想流程是JSAPI唤起支付。但如果wx.config失败，或wx.chooseWXPay调用报错（如invoke:fail invalid signature），前端必须能无感切换到H5支付。关键在于：降级动作必须由前端触发，但参数必须由后端重新生成。

流程如下：

1. 前端调用wx.chooseWXPay，监听fail回调
2. 在fail回调中，向后端发起/api/wx/fallback请求，传入原始订单ID
3. 后端收到请求，重新调用unifiedorderAPI，trade_type=MWEB，生成新的mweb_url
4. 前端拿到mweb_url，执行window.location.href = mweb_url

这里有两个细节决定成败：

• 订单幂等性：/api/wx/fallback接口必须检查该订单是否已存在H5支付记录，避免重复下单。我在Redis里用HSET fallback_orders {order_id} {mweb_url}，TTL设为10分钟。
• 用户体验：降级过程不能让用户感知到“失败”。我的做法是：在支付按钮上加一个旋转loading图标，fail回调触发后，图标继续旋转，同时静默跳转，用户只看到页面刷新了一下。

5.3 安全红线：永远不要在前端暴露API密钥

所有签名计算（JSAPI的paySign、H5的mweb_url签名、Native的sign）都必须在服务端完成。我见过太多团队为了“减少请求”，把密钥硬编码在React Native的index.js里，结果被反编译工具一键提取。微信支付密钥一旦泄露，攻击者可伪造任意订单，你的资金池将在