Beego做微信小程序后台完全可行，但需攻克code2Session调用、encryptedData+iv解密（AES-128-CBC+PKCS#7）、登录态鉴权（禁用Cookie Session，改用JWT或Redis校验X-WX-SESSION）三大环节。
Beego 做微信小程序后台完全可行，但直接照搬常规 REST API 写法会卡在 code2Session 解密、敏感数据校验、会话管理这三个关键环节上——尤其当小程序用的是 getPhoneNumber 一键登录时，后端没处理好 encryptedData 和 iv，前端就永远收不到手机号。
Beego 中正确调用微信 code2Session 接口
很多开发者在 controllers 里直接用 http.Get 拼 URL 请求微信接口，结果遇到重定向失败或 JSON 解析出错。根本原因是微信返回的不是标准 200 状态码（比如 errcode: -1），而 Beego 的 beego.HttpGet 默认不透传响应体。
推荐做法是用原生 net/http 并显式读取响应 Body：
resp, err := http.Get("https://api.weixin.qq.com/sns/jscode2session?" +
"appid=" + appId +
"&secret=" + appSecret +
"&js_code=" + code +
"&grant_type=authorization_code")
if err != nil {
return
}
defer resp.Body.Close()
body, _ := io.ReadAll(resp.Body)
// 必须手动检查 status code，不能只看 err
if resp.StatusCode != 200 {
beego.Error("wx code2Session http error:", resp.Status)
return
}
注意点：
-
appId和appSecret必须从conf/app.conf读取，别硬编码 - 微信返回的
session_key是 base64 编码的字符串，后续解密前要先base64.StdEncoding.DecodeString - 不要信任前端传来的
code，它 5 分钟过期，且一次只能用一次；服务端需记录已使用过的code（比如 Redis Set）防重放
在 Beego 中安全解密 encryptedData
小程序调用 getPhoneNumber 后传来的 encryptedData 是 AES-128-CBC 加密，密钥是 session_key，IV 是 iv。Beego 自身不提供 AES 解密工具，得自己写或引入 crypto/aes + crypto/cipher。
常见错误是忽略 PKCS#7 填充校验，导致解密后末尾出现乱码或 panic：
func decryptPhoneNumber(encryptedData, iv, sessionKey string) (string, error) {
key, _ := base64.StdEncoding.DecodeString(sessionKey)
ivBytes, _ := base64.StdEncoding.DecodeString(iv)
data, _ := base64.StdEncoding.DecodeString(encryptedData)
block, _ := aes.NewCipher(key)
mode := cipher.NewCBCDecrypter(block, ivBytes)
mode.CryptBlocks(data, data)
// 手动去 PKCS#7 padding
padding := int(data[len(data)-1])
if padding > len(data) || padding == 0 {
return "", errors.New("invalid pkcs7 padding")
}
return string(data[:len(data)-padding]), nil
}
关键提醒：
- 解密必须在拿到有效
session_key后立刻执行，session_key本身有效期约 2 小时，但微信不保证长期有效 - 解密失败时不要返回具体错误原因（如 “padding error”），统一返回
400 Bad Request，避免信息泄露 - 解密出的原始数据是 JSON 字符串，结构固定：
{"phoneNumber":"138****1234","purePhoneNumber":"13812341234",...}，务必校验phoneNumber字段存在且符合 11 位数字格式
Beego 路由与鉴权如何适配小程序登录态
小程序没有 Cookie，也不走浏览器同源策略，所以 Beego 默认的 beego.GlobalSessions 基于 Cookie 的 Session 机制基本失效。你不能靠 this.GetSession("uid") 判断用户是否登录。
真实可行的方案是：所有需要登录态的接口，强制要求 header 带 X-WX-SESSION（值为小程序 login 成功后存的 session_key 或自签发的 JWT），然后在 Filter 中统一校验：
beego.InsertFilter("/api/*", beego.BeeApp.Handlers, authFilter, true)
authFilter 示例逻辑：
- 从 header 取
X-WX-SESSION - 查 Redis，key 为
"wx:session:" + sessionKey，value 是uid和过期时间 - 若命中且未过期，把
uid注入到context.Input.Data["uid"]，后续 controller 可直接用 - 若未命中，返回
401 Unauthorized，前端跳回登录页
注意：session_key 本身不应直接当 token 用（微信明确不建议），更稳妥的是用它生成一个短期有效的 JWT，并把 uid 和时间戳塞进去，再用服务端私钥签名。
Beego 日志与错误码设计要匹配小程序客户端预期
小程序前端通常用 uni.showToast 展示错误，但如果你后端只返回 500 Internal Server Error 或空 body，用户看到的就是“操作失败”，完全不知道哪错了。
Beego 的 this.ServeJSON() 配合结构体能快速统一输出格式：
type Resp struct {
Code int `json:"code"`
Message string `json:"message"`
Data interface{} `json:"data,omitempty"`
}
// 在 controller 里
this.Data["json"] = &Resp{Code: 400, Message: "手机号解密失败"}
this.ServeJSON()
必须做到：
- 所有业务错误都用明确
Code：比如4001表示code已失效，4002表示手机号解密失败，4011表示登录态过期 - Beego 的
beego.Error日志里必须包含原始请求参数（code、encryptedData前 10 位等），但脱敏处理，不能打完整密文 - 上线前用
bee pack打包时确认conf/app.conf中runmode = "prod"，否则调试日志可能暴露敏感路径
最易被忽略的一点：微信的 session_key 是动态刷新的，小程序每次 login 都会换，但用户手机号不变。后端不能假设“同一个用户多次登录，session_key 可复用”，必须每次重新解密、重新绑定用户 ID —— 否则会出现 A 用户用 B 用户的手机号登录这种严重事故。
