S27-B04 · 微信生态：扫码登录与支付

适用读者：要接微信登录/支付的后端。
前置：S02-B06（HTTP/SSE）、S17-B04（网关）。
口径：具体接口参数以微信官方文档为准；本文讲机制与坑。
覆盖旧文：432(656) 431(598) + 相关 = 1,642 点。
覆盖扩展：E-S27-005（SSE 半长连接）、E-S27-011（支付幂等）。
上一篇：S27-B03 · 文件上传与文档处理全链路
下一篇：S27-J01 · 分布式可靠性四件套。

1. 一句话结论

扫码登录的本质是"用一次性票据把浏览器、手机、服务端三方串起来"：手机端确认后写入票据，浏览器端轮询/长连接拿到票据换登录态。

① 浏览器请求二维码（含 scene/ticket）
② 手机扫码 → 微信回调你的服务端（带 ticket + 用户标识）
③ 服务端记录"该 ticket 已确认"
④ 浏览器端通过 SSE/轮询获知 → 换取会话

2. 为什么用 SSE / 半长连接（E-S27-005）

方案	问题
短轮询（1s）	延迟与压力
长轮询	连接管理复杂
SSE	单向推送、实现简单、兼容好

SSE 注意点	说明
连接数	每用户一条连接，要设上限
超时重连	浏览器会自动重连，要防重复处理
网关超时	需关掉/调大代理超时（S15-A01）
鉴权	连接建立时校验，之后不再带 token

判据："客户端需要服务端主动通知吗？" 需要且单向 → SSE；双向 → WebSocket。

3. 支付的核心不是"调接口"，是幂等与对账（E-S27-011）

风险	措施
重复支付	业务订单号做唯一键（S17-J05）
回调重复	回调处理幂等（状态机 + 去重表）
掉单	主动查单 + 定时对账
金额篡改	服务端计算金额，不信前端

"为什么回调不能只处理一次就行"：微信会重试回调——你的回调必须幂等（S17-J03）。

4. 支付的四种形态与选择

形态	场景
Native（二维码）	PC 网站
H5	手机浏览器
JSAPI	微信内网页
小程序/APP	端内支付

判据："用户在什么环境里？" 决定形态——不是"哪个更先进"。

5. 五个误区

误区	真相
"扫码登录要手机一直在线"	只需一次确认
"SSE 不会断"	会重连，要幂等
"回调只来一次"	会重试
"支付成功就完事"	要对账/查单
"金额可以前端传"	必须服务端算

6. 自检

扫码登录的四步？
为什么选 SSE，注意哪四点？
支付四个风险的对应措施？
四种支付形态怎么选？
为什么回调必须幂等？

7. 下一篇

S27-J01 · 分布式可靠性四件套

微信讲完，进阶层开始：业务 Key、Single-flight、僵尸 Owner、Stage。

本篇属于系列《S27 · 杂项归档与工具实测》。旧文来源：A-432/431 + 相关卡；扩展点 E-S27-005/011。