Go语言搭建微信小程序后端教程

本文深入解析了使用Go语言开发微信小程序后端时的三大核心痛点：如何正确解析POST请求体（JSON与表单需显式处理，避免r.Body读取失效）、如何规范调用微信code2Session接口（严格遵循GET+URL参数、校验格式与编码、规避常见拼接陷阱），以及如何安全实现登录态管理（弃用session_key，仅持久化openid并搭配加密随机token存于Redis）。同时强调生产环境必须通过Nginx终止HTTPS，严禁Go直连TLS，并详解证书配置、域名匹配与调试排查要点——帮你绕过90%新手踩坑点，从开发到上线一步到位。

微信小程序调用 Go 后端时，POST 请求拿不到 body 怎么办

Go 默认的 http.Request 不会自动解析 application/json 或 application/x-www-form-urlencoded 的请求体，小程序发过来的 JSON 数据会“卡”在缓冲区里，r.Body 读出来是空的或报 http: request body too large。

常见错误现象：json.Unmarshal(r.Body, &v) 解析失败、r.FormValue("xxx") 返回空字符串、日志里看到 Content-Length: 123 但 io.ReadAll(r.Body) 读到空字节。

• 必须显式调用 r.ParseForm()（仅对 urlencoded 有效）或 r.ParseMultipartForm()（上传文件时），否则 r.PostForm 和 r.FormValue 都不可用
• 处理 JSON 时别直接读 r.Body 两次——第一次读完后 r.Body 就 EOF 了；要用 io.ReadAll 一次性读完再解析
• 小程序默认发的是 application/json，Go 后端别依赖 r.FormValue，老老实实用 json.NewDecoder(r.Body).Decode(&v)
• 如果用了 Gin/Echo 等框架，它们内部已做处理，但自建 http.ServeMux 时这点最容易漏

小程序登录态校验：用 code2Session 接口验 session_key 时为啥总返回 invalid appid

不是 AppID 写错了，而是请求参数没按微信要求拼——code2Session 是 GET 请求，所有参数必须作为 URL 查询参数传，且 appid、secret、js_code、grant_type 缺一不可，顺序无关但大小写敏感。

典型翻车点：secret 从环境变量读出来带换行符、js_code 从小程序 login 成功回调里取值时没 trim 空格、URL 拼接时忘了 url.QueryEscape 处理中文或特殊字符。

• 微信接口地址必须是 https://api.weixin.qq.com/sns/jscode2session，不能少 sns/，也不能写成 https://api.weixin.qq.com/cgi-bin/...
• grant_type 只能是字符串 "authorization_code"，不是 "code" 也不是 "auth_code"
• 用 net/http 发请求时，别用 http.Post——它发的是 POST，而 code2Session 要 GET；改用 http.Get 或构造 *http.Request 手动设 Method = "GET"
• 响应要检查 err == nil 且 resp.StatusCode == 200，再解析 JSON；微信出错时也返回 200，但 body 里有 errcode 字段

Go 后端怎么安全存用户 openid 和 session_key

别存 session_key ——它本就是临时密钥，有效期约 2 小时，且微信明确不建议长期存储；真正该持久化的是 openid（用户唯一标识），配合自产的短期 token 做本地会话管理。

常见错误：把 session_key 当作登录凭证存在 Redis 里，过期后无法刷新；或者把 openid 直接当 API Token 透传给前端，导致账号被撞库或冒用。

• 收到 code2Session 响应后，只提取 openid 和 unionid（如果绑定了开放平台），丢掉 session_key
• 用 crypto/rand 生成 32 字节随机 token，和 openid 一起存 Redis，设置 TTL（比如 7 天），key 格式建议 token:
• 小程序每次请求带上自定义 header X-Auth-Token，后端查 Redis 验证是否存在对应 openid，不碰微信任何密钥
• 避免用 Go 的 time.Now().Unix() 做 token，容易被预测；也不要用 math/rand，它不加密安全

部署时 http: TLS handshake error 导致小程序请求 400

小程序强制要求后端 HTTPS，但本地开发用 http.ListenAndServe(":8080", nil) 是 HTTP；上线后若用 Nginx 反向代理但没配好 TLS 终止，或证书链不全，Go 进程本身又没启 HTTPS，就会在日志里刷 TLS handshake error，小程序客户端收不到响应，表现为超时或 400 错误。

这不是 Go 代码问题，是基础设施层配置偏差。微信校验域名时会走完整 TLS 握手，任何环节断开都会失败。

• 生产环境别让 Go 直接跑 HTTPS——用 Nginx/Apache 做 TLS 终止，Go 后端只监听 localhost:8080 的 HTTP，更轻量也更安全
• Nginx 配置里必须包含 ssl_certificate 和 ssl_certificate_key，且证书文件得是 PEM 格式，不能是 PFX 或 JKS
• 检查证书是否由可信 CA 签发（Let’s Encrypt 可以，自签不行），用 openssl s_client -connect yourdomain.com:443 看输出里有没有 Verify return code: 0 (ok)
• 小程序后台配置的服务器域名，必须和证书里的 Subject Alternative Name 完全一致，不支持泛域名匹配（*.a.com 不认 api.a.com）

最麻烦的其实是证书更新后 Nginx 没 reload，或者 DNS 解析还没切到新 IP——这些地方查起来比写 Go 代码还花时间。

今天关于《Go语言搭建微信小程序后端教程》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！