企业官网建设流程全解析

PC端网页里接支付，很多人第一反应是“调个接口不就完了”，真上手才发现坑全在细节里：微信那边要区分扫码模式和跳转模式，支付宝的电脑网站支付和手机网站支付参数结构完全不一样，回调地址配错一个字符就永远收不到异步通知，前端轮询订单状态时又容易把用户晾在“支付中”的页面干等。这篇就把我在Vue项目里落地PC端微信支付和支付宝支付的全过程拆开讲，从后端下单接口的字段设计、前端二维码渲染与轮询策略，到回调验签、订单状态机、异常兜底，尽量把每一步“为什么这么做”说清楚。适合已经能写Vue、但对支付链路还没完整跑通过的同学，也适合接过别人半成品支付模块、正在排查“为什么钱扣了订单还是待支付”的同行参考。

1. 先把支付链路的地图画清楚再动手写代码

支付这件事最怕的就是上来就写代码。我见过不少项目，前端直接调一个“下单接口”，拿到个字符串就往页面上怼，结果二维码扫不出来、跳转链接打不开、支付成功了页面还在转圈。根子在于没搞清楚整条链路里谁负责什么。PC端网页支付，本质上是三方协作：你的前端页面、你的后端服务、第三方支付平台。前端永远不直接和支付平台打交道，所有敏感操作（下单、验签、查单）都在后端完成，前端只负责展示和引导。

1.1 微信支付与支付宝支付在PC场景下的形态差异

先明确一个前提：PC端网页里，微信支付和支付宝支付能用的产品类型是不一样的，这直接决定了前端交互长什么样。

微信支付在PC网页场景下，主流是Native支付，也就是我们常说的“扫码支付”。后端调用统一下单接口，拿到一个二维码链接（code_url），前端把它渲染成二维码图片，用户拿手机微信扫一扫完成付款。另一种是JSAPI支付，但那个依赖微信内置浏览器环境，PC端普通浏览器里用不了，所以PC场景基本就是Native一条路。还有个H5支付，那是给手机浏览器网页用的，PC端不适用。这点必须先厘清，否则你会拿着H5支付的参数在PC上怎么调都不对。

支付宝在PC场景下对应的是电脑网站支付（alipay.trade.page.pay），它的典型形态是：后端生成一个表单或者跳转链接，前端把用户浏览器直接导向支付宝的收银台页面，用户在支付宝页面完成登录和付款，然后跳回你的return_url。它也有扫码的形态（当面付的预下单），但PC网页最标准、最省事的还是电脑网站支付跳转。

这个差异带来的直接后果是：微信支付是“留在你的页面扫码”，支付宝支付是“离开你的页面去收银台”。两种交互模型完全不同，前端的状态管理逻辑必须分开设计，不能一套代码硬套。

1.2 一次完整支付要经过的六个环节

把链路拆细，一次成功的PC支付大致经过这些环节：

1. 用户在订单确认页点击“去支付”，选择微信或支付宝；
2. 前端带着订单号调用后端“创建支付”接口；
3. 后端根据支付方式调用对应平台的下单API，拿到支付凭证（微信是code_url，支付宝是跳转表单/链接）；
4. 后端把凭证返回前端，同时把订单状态置为“待支付”，记录交易流水；
5. 前端根据凭证做展示：微信渲染二维码并开始轮询订单状态，支付宝则提交表单跳转；
6. 用户完成付款后，支付平台异步回调后端（notify_url），后端验签、核对金额、更新订单状态；前端轮询到“已支付”后跳转结果页。

这里有个关键认知：异步回调才是订单状态更新的唯一可信来源，前端轮询只是“问结果”，不能“定结果”。很多新手会犯的错是前端轮询时自己把订单标记成已支付，这是极其危险的，因为轮询请求可能被伪造，而支付平台的异步通知带签名，才是可信的。

1.3 为什么前端绝不能碰密钥和验签

支付平台的商户私钥、API密钥这些东西，一旦出现在前端代码里，等于把保险柜钥匙贴在门上。前端打包后的代码是公开可读的，任何人打开开发者工具都能看到。所以下单、验签、查单、退款这些操作必须全部在后端完成，前端拿到的只能是“已经处理好的、可以安全暴露的凭证”。这条红线在Vue项目里尤其要注意，因为前端工程化程度高，很容易有人图省事把签名逻辑写进前端工具函数里，这是绝对不允许的。

2. 后端下单接口的字段设计决定了前端好不好写

前端写支付顺不顺畅，很大程度上取决于后端接口设计得合不合理。我接手过一个项目，后端下单接口对微信和支付宝返回的字段结构完全不一样，前端得写两套解析逻辑，维护起来痛苦不堪。所以这一节虽然是讲“后端”，但作为前端也得懂，因为你要能判断接口设计是否合理，不合理要能提出来。

2.1 统一的下单响应结构设计

我的建议是，无论微信还是支付宝，后端对前端暴露的下单响应结构尽量统一，用一个字段区分支付类型，其余字段按需填充。一个比较实用的结构是这样的：

{ "code": 0, "data": { "payType": "wechat_native", "orderNo": "20240520123456", "amount": "99.00", "payPayload": { "codeUrl": "weixin://wxpay/bizpayurl?pr=xxxxx" }, "expireTime": 1716200000 } }

支付宝的话，payType换成alipay_page，payPayload里放的是formHtml或者payUrl。这样前端只需要判断payType，然后从payPayload里取对应字段，逻辑清晰。expireTime这个字段很关键，二维码和收银台链接都是有有效期的（微信Native默认2小时，支付宝可配置），前端要据此做倒计时和过期提示，避免用户对着一个已经失效的二维码扫半天。

2.2 金额单位与订单号的坑

金额单位是支付对接里最经典的坑。微信支付的金额单位是分，支付宝电脑网站支付的total_amount单位是元，保留两位小数。如果后端不统一处理，前端展示时就会出现“99元订单显示成0.99元”或者“9900元”这种灾难。我的做法是：后端内部统一用分存储，对外接口统一返回元（字符串，两位小数），前端只负责展示，不做任何单位换算。换算逻辑集中在一处，出错概率最低。

订单号也有讲究。商户订单号（out_trade_no）必须全局唯一，且长度、字符集要符合平台要求。微信要求6到32个字符，支付宝要求不超过64个字符。我一般用“业务前缀+时间戳+随机数”的格式，比如ORD20240520143025123456，既保证唯一，又方便排查问题时一眼看出下单时间。千万别用纯自增ID，一是容易暴露业务量，二是分库分表后可能重复。

2.3 回调地址与前端返回地址的配置

这里有两个地址必须分清，混淆了就是无尽的排查：

• notify_url（异步通知地址）：支付平台服务器直接POST调用你的后端接口，用来通知支付结果。这个地址必须是公网可访问的、不能带登录鉴权的接口。它决定了你的订单能不能被正确标记为已支付。
• return_url（同步跳转地址）：用户支付完成后，浏览器被重定向回你的页面。这个地址是给用户看的，用来展示“支付成功”页面。它不可信，因为用户可以手动改地址栏，所以绝不能仅凭return_url的到达就判定支付成功。

微信Native支付其实没有return_url的概念（因为是扫码，用户没离开你的页面），但支付宝电脑网站支付有。配置时，notify_url一定要用内网穿透或者正式域名，本地开发时用localhost是收不到回调的，这点后面会专门讲。

3. 微信Native支付：二维码渲染与轮询的完整实现

微信Native支付的交互核心就两件事：把code_url变成用户能扫的二维码，以及支付后怎么知道成功了。看似简单，但二维码生成方式、轮询频率、过期处理，每个点都有讲究。

3.1 code_url到二维码：选qrcode还是qrcodejs2

code_url本身是一个weixin://开头的字符串，不是图片。前端需要把它转成二维码图片。Vue项目里常用的库有两个：qrcode（node-qrcode）和qrcodejs2。我实测下来更推荐qrcode，原因是它支持Canvas和SVG两种渲染，API更现代，而且对Vue3的兼容性更好。qrcodejs2比较老，是基于DOM的，在Vue的响应式更新里偶尔会出现重复渲染的问题。

用qrcode生成二维码的核心代码大概是这样：

import QRCode from 'qrcode' async function renderQrCode(codeUrl, canvasEl) { await QRCode.toCanvas(canvasEl, codeUrl, { width: 240, margin: 1, errorCorrectionLevel: 'M' }) }

errorCorrectionLevel选M（中等纠错）就够了，选太高会让二维码变密，反而不好扫。margin设1，留一点白边，扫码识别率更高。这里有个细节：二维码容器在弹窗里时，如果弹窗还没渲染完就调toCanvas，canvas尺寸会是0，二维码画不出来。解决办法是在nextTick之后或者弹窗的opened回调里再渲染。

3.2 轮询订单状态：频率、终止条件与页面隐藏处理

用户扫码付款后，前端怎么知道成功了？答案是轮询后端查单接口。轮询看着简单，但写不好就是灾难：频率太高给后端压力大，频率太低用户等得着急，不设终止条件就是无限请求。

我的实践方案是：间隔3秒轮询一次，最多轮询到二维码过期时间为止，页面切到后台时暂停轮询。具体逻辑：

let timer = null let pollCount = 0 const MAX_POLL = 100 function startPolling(orderNo, expireTime) { timer = setInterval(async () => { pollCount++ const now = Math.floor(Date.now() / 1000) if (now >= expireTime || pollCount > MAX_POLL) { stopPolling() showExpiredTip() return } const res = await queryOrderStatus(orderNo) if (res.status === 'PAID') { stopPolling() router.replace('/pay/success') } else if (res.status === 'CLOSED') { stopPolling() showClosedTip() } }, 3000) } function stopPolling() { if (timer) { clearInterval(timer) timer = null } }

为什么要处理页面隐藏？因为用户扫码时往往会切到手机，PC页面在后台，浏览器会节流定时器，轮询可能变得不准。更稳妥的做法是监听visibilitychange，页面重新可见时立即查一次，然后恢复轮询。另外组件卸载时一定要clearInterval，否则定时器泄漏，用户离开页面后还在请求，既浪费资源又可能触发一些奇怪的状态更新报错。

3.3 二维码过期与用户主动取消的处理

二维码过期是常态，不是异常。微信Native的code_url有效期默认2小时，但实际业务里我们往往希望更短，比如15分钟，避免用户挂着一个旧二维码。过期后前端要明确提示“二维码已过期，请刷新重试”，并提供一个刷新按钮重新下单。这里要注意，重新下单会生成新的订单号还是复用原订单号？我的建议是复用原业务订单号，但生成新的支付流水号，因为同一个业务订单可能多次发起支付，每次的code_url都不同。

用户主动取消（比如关掉弹窗）时，前端要停止轮询，但不要去调用关单接口。关单应该由后端在订单超时后统一处理，前端贸然关单可能导致用户其实已经付款但订单被关掉的尴尬局面。这个边界要划清楚。

4. 支付宝电脑网站支付：表单跳转与回跳页面的状态还原

支付宝电脑网站支付的交互模型和微信完全不同：用户要离开你的页面，去支付宝的收银台。这带来两个新问题：怎么跳过去，以及跳回来之后怎么知道支付结果。

4.1 form表单自动提交跳转的实现细节

支付宝电脑网站支付后端返回的通常是一段自动提交的HTML表单，形如：

<form name="punchout_form" method="post" action="https://openapi.alipay.com/gateway.do?..."> <input type="hidden" name="biz_content" value="..."> ... <input type="submit" value="立即支付" style="display:none"> </form> <script>document.forms['punchout_form'].submit();</script>

前端拿到这段HTML后，不能简单地用v-html塞进页面，因为里面的<script>不会执行。正确做法是把它写到一个新窗口或者当前窗口的document里。我一般用当前窗口跳转，体验更连贯：

function submitAlipayForm(formHtml) { const div = document.createElement('div') div.innerHTML = formHtml document.body.appendChild(div) const form = div.querySelector('form') if (form) { form.setAttribute('target', '_self') form.submit() } }

注意target要设成_self，否则可能开新标签页。还有一种做法是后端直接返回payUrl，前端window.location.href = payUrl，更简单，但要注意URL长度限制和参数编码。两种方式都行，看后端实现。

4.2 return_url回跳后的订单状态确认

用户付完款，支付宝会把浏览器重定向回return_url，通常带着out_trade_no、trade_no等参数。这时候绝对不能直接显示“支付成功”，因为return_url的参数可以被伪造。正确流程是：回跳页面拿到out_trade_no，调用后端查单接口，以后端查询到的真实状态为准。

onMounted(async () => { const orderNo = route.query.out_trade_no if (!orderNo) { showError('订单信息缺失') return } const res = await queryOrderStatus(orderNo) if (res.status === 'PAID') { showSuccess() } else if (res.status === 'PENDING') { // 异步通知可能还没到，稍等再查 setTimeout(() => recheck(orderNo), 2000) } else { showFail() } })

这里有个真实会遇到的情况：用户付款很快，但支付宝的异步通知可能比浏览器回跳慢几秒。所以回跳页面查到“待支付”时不要立刻判失败，应该延迟重查几次。我一般重查3次，间隔2秒，还查不到再提示“支付结果确认中，请稍后到订单列表查看”。

4.3 收银台页面被拦截或用户中途放弃的兜底

用户点了支付但没完成，直接关了支付宝页面，这种情况很常见。前端无法感知，只能靠后端定时任务去查单：对于超过一定时间（比如30分钟）仍是待支付的订单，后端主动调用支付宝的查单接口确认，如果确实未支付就关闭订单。前端这边，用户下次回到订单列表时，看到的状态应该是准确的。所以订单列表页的状态展示也要走查单逻辑，不能只读数据库里的旧状态。

5. 异步回调验签：订单状态可信更新的唯一入口

前面反复强调异步回调的重要性，这一节就把它讲透。回调处理写错，轻则订单状态不更新，重则被伪造通知薅羊毛。

5.1 微信支付回调的验签与解密流程

微信支付V3的回调用的是AEAD_AES_256_GCM加密，回调体里的resource字段是密文，需要用APIv3密钥解密后才能拿到明文。验签则依赖请求头里的Wechatpay-Signature、Wechatpay-Timestamp、Wechatpay-Nonce和平台证书。流程大致是：

1. 从请求头取出签名相关字段；
2. 用平台证书公钥验证签名；
3. 用APIv3密钥解密resource，得到订单明文；
4. 核对out_trade_no和金额；
5. 更新订单状态；
6. 返回{"code":"SUCCESS","message":"成功"}给微信。

任何一步失败都要返回失败响应，让微信重试。这里的关键是金额核对：解密出来的amount.total必须和你数据库里该订单的应付金额一致，不一致要告警并拒绝更新。这是防止金额篡改的最后一道防线。

5.2 支付宝回调的验签与幂等处理

支付宝的回调用的是RSA2验签，把回调参数按规则排序拼接，用支付宝公钥验证sign字段。验签通过后，还要检查trade_status是否为TRADE_SUCCESS或TRADE_FINISHED，以及total_amount是否匹配。

幂等处理是回调里必须做的。支付平台可能重复发送通知（比如你响应慢了），所以更新订单状态前要先判断：如果订单已经是“已支付”，直接返回success，不要重复处理。我一般用数据库的乐观锁或者状态机来保证：UPDATE orders SET status='PAID' WHERE order_no=? AND status='PENDING'，受影响行数为0说明已经处理过，直接返回成功即可。

5.3 回调接口的常见配置错误排查

回调收不到，九成是这几个原因：

特别提醒：本地开发时，notify_url填localhost是绝对收不到的，必须用内网穿透工具把本地端口映射出去，或者直接在测试环境联调。这个坑几乎每个新手都会踩一次。

6. 订单状态机与前端交互的收尾设计

支付做完了，但用户体验的最后一公里在状态展示上。订单状态设计得乱，用户就会困惑“我到底付没付成功”。

6.1 一套够用的订单状态定义

我一般用这几个状态：PENDING（待支付）、PAID（已支付）、CLOSED（已关闭）、REFUNDING（退款中）、REFUNDED（已退款）。状态流转必须是单向的、有明确触发条件的：PENDING只能由回调或主动查单转为PAID，超时任务把PENDING转为CLOSED，PAID才能发起退款。前端根据状态展示不同的按钮和文案，比如PENDING显示“继续支付”，PAID显示“查看订单”，CLOSED显示“重新下单”。

6.2 支付结果页的防刷新与防重复提示

支付成功页有个细节：用户刷新页面，不应该重复触发查单或者重复提示。我的做法是结果页从路由参数拿orderNo，查一次状态后把结果存在组件状态里，刷新时重新查一次但只做展示，不做任何写操作。同时，成功页要提供“查看订单详情”和“继续购物”两个出口，别让用户卡在成功页不知道下一步干嘛。

6.3 我在实际项目里踩过的三个坑

第一个坑：二维码在弹窗里渲染不出来。原因是弹窗动画还没结束，canvas尺寸为0。解决办法是在弹窗@opened事件里渲染，或者用nextTick加一个短延迟。

第二个坑：轮询定时器没清理，用户切走页面后还在请求，控制台一堆报错。后来在onBeforeUnmount里统一清理，并且加了页面可见性判断。

第三个坑：支付宝回跳页面直接显示成功，结果有用户伪造URL骗过了前端，虽然后端订单没变，但用户体验很混乱。后来改成回跳页面必须查后端状态，前端不再自己判断。

支付这块，接口调通只是开始，真正花时间的是这些边界情况和异常兜底。把状态机设计清楚、把回调验签做扎实、把前端轮询和过期处理写严谨，这套PC端支付才算真正能上线。后面如果业务扩展到退款、对账，这套状态和流水设计也能直接复用，不用推倒重来。