面向用 AI 写代码的非专业开发者，提供一套 AI 协作开发…

# 登录超时反复修不好：补丁 vs 架构问题诊断

一、先判断：大概率是架构根因

AI连续三次修复无效，典型信号是：每次改动都针对症状（延长超时时间、加重试、加loading提示），而非追问“为什么会超时”。这符合架构级问题的特征。

二、常见根因排查清单（按小程序场景概率排序）

• 会话存储位置问题：微信小程序场景下，token/session存在内存而非持久化存储，小程序切后台或重启即丢失，导致“每次进来都超时”。应改用 wx.setStorageSync 持久化。
• 后端会话机制错配：服务端用内存Session（如默认的Express-session、单机内存map），多实例部署或服务重启即失效。应迁移到Redis或改用JWT。
• JWT设计缺陷：token有效期过短、无refresh token机制、或微信code2session流程与自有鉴权体系没打通。
• 前端请求层问题：没有统一的token注入/401拦截/静默刷新逻辑，各页面各自处理，改一处漏一处——这也解释了为什么AI“改了三次”：它在不同文件里打补丁。
• 冷启动/网关超时：云开发冷启动、后端接口本身响应慢，被误判为“登录超时”。

三、自测方法（10分钟定位）

1. 复现时打开抓包（开发者工具Network面板），看超时是前端主动abort还是接口真超时。

2. 若接口正常返回但前端判超时 → 前端拦截器/超时阈值问题。

3. 若token频繁401 → 查服务端会话存储方式。

4. 若仅冷启动后超时 → 服务端性能问题，非登录架构问题。

四、给AI的正确提问方式

不要说“再修一次超时”，而是：

• “登录链路涉及哪些文件？先输出完整调用链再谈修复”
• “请对比三次修改的差异，判断是否在打补丁”
• 直接提供抓包结果让它基于证据分析。

五、结论建议

这是架构问题的概率很高（会话存储设计 + 缺乏统一鉴权层）。正确解法是设计一个统一的请求拦截层 + 持久化会话方案，一次性重构登录链路，而不是继续让AI逐点修补。重构工作量通常在数小时级别，远低于反复试错的累计成本。