微信支付v3在Go项目中必须使用官方wechatpay-go SDK，严格遵循证书验签、APIv3密钥加密、RFC3339时间格式、自动重试与幂等控制等规范，手写客户端或使用非官方库易导致生产事故。
微信支付在 Go 项目里不是“加个 SDK 就能用”，而是必须严格遵循 v3 接口规范；用错 SDK、跳过证书加载、忽略幂等校验，上线后基本等于裸奔。
必须用 wechatpay-go，别碰非官方库
微信支付 v3 强制要求平台证书验签、APIv3 密钥加密、RFC3339 时间格式、自动重试与幂等控制。手写 HTTP 客户端几乎无法正确实现全部规范：
-
github.com/go-pay/wechat不支持平台证书自动轮换，验签逻辑有已知漏洞，2025 年起已被多个生产事故复现 -
github.com/wxp/wxpay是 v2 封装库，不兼容 v3 接口，调用UnifiedOrder会返回401 unauthorized或400 invalid request - 官方
wechatpay-go自动管理Wechatpay-Serial头、证书刷新、Authorization签名头生成（基于私钥 + 请求体 + 时间戳 + 随机数）
初始化 client 必须传入平台证书和私钥文件路径
只填 AppID、MchID、ApiV3Key 是不够的——v3 接口所有敏感请求（统一下单、查询、退款）都需双向 TLS 认证 + 请求签名：
- 从微信商户平台「API安全」页下载「平台证书」（.pem）和「商户私钥」（.pem），不要用 API 密钥文本代替私钥
- 初始化时必须显式加载证书：
wechatpay.NewClient(..., wechatpay.WithWechatPayCertificate(certBytes)) - 若证书过期或序列号不匹配，
client.PayTransactionsJsapi()会直接 panic，错误信息为"invalid certificate serial number"
回调通知处理必须解密 + 验签 + 幂等判断
微信服务器发来的 POST /notify 请求体是 AES-GCM 加密的 JSON，不能直接解析；且通知可能重复发送（网络抖动、超时重试）：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 先用
client.DecryptNotification()解密，得到原始 JSON；若失败，返回 HTTP 200 +"success"，**不能抛错或返回 5xx** - 解密后检查
resource.algorithm == "AEAD_AES_256_GCM"，再对resource.ciphertext做验签（SDK 已封装） - 用
out_trade_no查询本地订单状态；若已是paid，立即返回"success"，不执行任何更新逻辑 - 推荐用 Redis SETNX + EXPIRE 300 秒，以
notify_id为 key，防重放（微信通知中带该字段）
前端调起 JSAPI 支付前，后端必须先统一下单并返回 prepay_id
小程序或公众号内网页调起微信支付，不是前端传金额就完事，而是要走标准三步：
- 后端调
client.PayTransactionsJsapi()，传appid、mchid、description、amount（单位分）、payer（含 openid）、notify_url - 拿到响应中的
prepay_id，拼成签名参数：包括appId、timeStamp（秒级时间戳字符串）、nonceStr、package（固定值"prepay_id=xxx"）、signType（固定"RSA"） - 用商户私钥对上述参数做
rsa.SignPKCS1v15签名，返回给前端；前端调wx.requestPayment时传入这些参数 - 若漏掉
timeStamp格式（必须是字符串而非数字）或签名参数顺序错乱，前端报错"requestPayment:fail invalid sign"
最常被跳过的其实是证书生命周期管理和通知幂等性——证书默认 2 年过期，但微信可能提前 30 天轮换；而一次支付通知重复到达两次，若没判重，就会扣两次款、发两次货。
