TRAE-AI编程
小程序授权登录是高频功能，也是出错率最高的环节之一。表现通常是：点了授权没反应、code 换 openid 失败、或登录态刚拿到就过期。多数问题不在后端，而在前端调用顺序和参数理解上。本文先讲清正常链路，再给三个最高频的出错原因与修法，照着排查基本能一站定位。先给结论：每次登录重新 wx.login 拿新 code 立刻发后端，登录态存 Storage，授权范围最小化。下面按“链路—原因—修复”的顺序一步步来。
一、先弄清正常登录链路（前置与边界）
用户进入小程序，点“微信登录”，前端调用 wx.login() 拿到 code，把 code 发给后端，后端用 code 换 openid 和 session_key，再下发自定义登录态。边界要划清：code 是临时的，约 5 分钟有效且只能换一次，不能缓存复用。想系统学小程序开发，可参考 微信小程序开发文档。
理解这一点能避开最大误区：有人把 code 存进变量反复用，第二次用旧 code 换 openid 直接报错。安装依赖并配置好请求封装后，正确思路是“每次登录都重新 wx.login，拿到立刻发后端”。配置上，前端拿到 code 后应通过 HTTPS 发给自己的服务端，不要在前端直接拼 openid，那会泄露密钥逻辑。把“code 即用即弃”当成铁律，后面三种原因才不会反复出现。一次完整的小程序登录，前端只负责拿 code，其余交给后端；资料授权另走隐私流程，不要混进登录链路。
实际项目里，授权登录还涉及用户信息（昵称头像），这部分要走新版隐私授权或头像昵称填写能力，而不是老 getUserInfo。所以前置要明确：登录（拿 code）和授权（拿资料）是两件事，可以分开触发，不要混在一起导致流程错乱。这个边界想清楚，后面无论排查哪种出错，都能先判断是登录链路还是资料授权，也方便接手的人照同一套顺序接手。
二、最稳的登录写法（配置与运行）
最稳的写法是“先 wx.login 拿 code，再发后端换 openid”，不要自己拼 openid。code 是临时的，有效期约 5 分钟，且只能换一次，拿到立刻发后端最稳。运行命令前确认 wx.login 在用户点击后触发。关于前端调用基础，可看 JavaScript 教程。
async function doLogin() {
const { code } = await new Promise((resolve) =>
wx.login({ success: resolve, fail: resolve })
);
const r = await wx.request({ url: '/api/login', data: { code } });
wx.setStorageSync('token', r.data.token);
}前端只负责把 code 交给后端，openid 和 session_key 都由后端持有，密钥不落前端。配置要点：后端换到 openid 后下发自定义 token，前端存起来作为后续请求凭证。这个写法是小程序授权登录最稳的底座，优先采用，能避开九成的前置错误。
实践里建议把 doLogin 封装成幂等方法，调用方只管“要登录就调它”，内部保证 code 新鲜、请求带兜底。比起“在多个页面各写一遍 wx.login”，统一封装能保证登录态逻辑只有一份，排查时也只需看一个函数。新人接手不会被散落的登录代码搞晕，也不会因为某处忘了刷新 code 而踩“code 已使用”的坑。
三、授权范围的取舍（验证与预期）
如果你需要用户昵称头像，要走“头像昵称填写”能力或新版隐私授权，而不是老的 getUserInfo（已回收）。预期结果是：用户主动填写后，前端拿到昵称头像，授权范围最小化。可看 HTML 教程 理解页面结构。
验证时打印后端返回的 token 是否存在、Storage 是否写进；再模拟“未授权就点登录”，确认流程给出明确提示而不是静默失败。它的同步写法观感不如一步到位直接，但在“隐私合规”场景下是必要的，属于按需选用，而不是一律强求。把授权范围收到最小，既能过审，也减少用户抵触。
要注意授权和登录可以解耦：登录拿 token 不需要用户资料，资料授权可在需要时再弹。验证数据流向时，可以在控制台看两次请求的入参，确认登录只带 code、授权才带资料。把验证做扎实，小程序授权登录的流程才不会在边界处悄悄错位，也方便后续接手的人照着同样的方式补授权能力。
四、三个常见出错原因与修复（失败与排错）
原因一：wx.login 的 code 重复使用或过期，后端用旧 code 换 openid 直接报错。解决是每次登录重新 wx.login，不缓存 code。原因二：把 wx.login 和授权按钮的回调混在一起，用户没点授权就先 login，导致流程错乱。样式相关可看 CSS 教程。
原因三：登录态没持久化或存错地方，token 只放内存，页面一切换就丢，表现为“刚登录又让我登”。应存到 Storage 并在启动时读取。失败分支里最隐蔽的是“code 已使用”，后端返回 errcode 提示，前端却没重试 wx.login，直接把错误甩给用户。把这三个原因记牢，小程序授权登录就能一站定位。
还有一个原因：在开发者工具里登录正常、真机失败，多半是环境差异（如真机未登录微信、基础库版本低）。失败修复时，先抓后端返回的 errcode 对照文档，再区分是 code 问题还是网络问题。把这类边界写进排查清单，运营反馈“登不进”时，照清单一步步勾，比凭感觉改代码高效得多。
五、适用边界与替代方案（安全与对比）
wx.login + 后端换 openid 适合绝大多数小程序；若你用第三方服务商，可考虑其登录 SDK 少写后端，但绑定了供应商、迁移成本高。对比来看，自建换 token 换的是可控，SDK 换的是省事。关于保存可复现示例，可看 Python 教程。
适用边界上：自有后端优先自建登录链路；快速验证阶段可用 SDK。安全上，token 必须存 Storage 而非内存，且设置过期与刷新；openid/session_key 绝不能下发到前端。小程序授权登录的本质是“前端只交 code、后端守密钥”，把边界和替代方案想清楚，登录才不会既错又难查，也能在需要时果断切换到更省事的方案。
从工程安全角度，token 要带过期时间，并在临近过期时用静默刷新续期，而不是每次都跳登录页。更好的做法是把登录态封装成拦截器，请求 401 自动刷新再重发。这样小程序授权登录既是可用性问题，也是安全问题：它让用户无感续期，又保留了密钥不落前端的本质优势（编辑推断）。
总结
小程序授权登录总出错，九成出在前端：code 复用或过期、login 与授权按钮回调错位、登录态没持久化。最稳的做法是每次登录重新 wx.login 拿新 code 立刻发后端，登录态存 Storage，授权范围最小化。排查时先看 code 和 errcode，问题基本一目了然。
常见问题
Q：为什么后端用 code 换 openid 总失败？
多半是 code 过期或已被用过，wx.login 的 code 约 5 分钟有效且只能换一次，每次登录都要重新获取。
Q：老 getUserInfo 拿不到头像昵称了？
该接口已回收，需改用头像昵称填写能力或新版隐私授权流程，别再依赖旧接口。
Q：登录态为什么一切换页面就没了？
token 只放内存会随页面销毁丢失，应写入 Storage 并在启动时读取恢复。
