支付结果页必须依赖后端真实状态，禁止用URL参数或localStorage判断；应通过轮询后端订单状态接口获取防篡改结果，并安全跳转与渲染。
支付结果页不是前端能独立决定状态的页面，它必须依赖后端返回的真实支付结果，否则会出资金问题。
为什么不能用 URL 参数或本地 localStorage 判断支付成功
很多开发者想省事，用 ?status=success 或存个 pay_result 到 localStorage 就直接显示“支付成功”，这是危险操作。用户可以手动改 URL、清缓存、甚至用调试工具伪造状态——一旦误判，订单状态和资金流水就对不上。
- 真实支付结果只能由后端通过支付平台回调（如微信 notify、支付宝异步通知）校验签名后落库，并提供唯一、防篡改的查询接口
- 前端页面加载时，必须调用后端提供的「查询订单支付状态」接口（例如
/api/order/status?order_id=123456），而不是读客户端数据 - 该接口应返回明确字段：如
status: "paid"、"failed"、"pending"，且带时间戳和可验证的业务一致性（比如金额匹配）
怎么设计一个防重刷、防跳过、有兜底的支付结果页
用户可能关闭页面、切后台、网络中断，再回来时需要准确呈现最终状态，而不是重新发起支付或显示空白。
- 页面初始化立即发起轮询（建议最多 3–5 次，间隔 1s/2s/3s），调用
/api/order/status，直到返回paid或failed；若超时仍为pending，显示“处理中，请稍候”，并提供「手动刷新」按钮 - 禁止用户在结果页点浏览器后退 —— 可用
history.replaceState()覆盖初始 history entry，避免回退到支付页重复提交 - 所有按钮（如「查看订单」「返回首页」）必须等接口返回确定状态后再启用，不要默认可点
- 失败页要明确展示错误原因（如
err_code: "PAYMENT_CLOSED"），但不暴露敏感信息（如银行卡号、签名原文）
微信/支付宝 H5 支付后如何安全跳转到结果页
支付 SDK 的 success 回调只是“用户完成支付动作”，不代表资金已到账或商户已收款，绝不能在此刻跳转到 success.html。
立即学习“前端免费学习笔记（深入）”；
- 微信 JSAPI 支付：服务端统一下单后返回
paySign，前端调用wx.requestPayment，其success回调只表示用户点确认并输完密码，此时必须立刻跳转到后端生成的、带order_id的结果页（如/pay/result?order_id=abc123） - 支付宝网页支付：前端跳转到
https://openapi.alipay.com/gateway.do?...后，支付宝会在支付完成后重定向回你配置的return_url—— 这个地址必须是后端路由（如/pay/alipay/return），由后端校验sign并写入状态，再 302 跳转到真正的结果页 - 永远不要把
return_url或redirect_uri指向纯静态 HTML 文件
最常被忽略的一点：结果页的「查看订单」按钮链接，必须指向服务端渲染的订单详情页（如 /order/123456），而不是前端路由 /#/order/123456 —— 后者无法保证用户登录态和数据新鲜度，容易出现“查不到刚支付的订单”。
