用户在小程序里填了二十多分钟报销单，点提交却跳回登录页，是登录态到期了还是表单没暂存？

结论先行：用户在小程序里填了二十多分钟报销单，点提交却跳回登录页，多数不是账号被人顶了，而是登录态（token）到期后，前端既没提前续期，也没在接口返回鉴权失败时排队重放请求；如果表单内容还没做本地暂存，用户看到的就是“白填了”。2026 年常见做法是把登录态拆成短效访问凭证加长效刷新凭证：临近过期时静默换新票，遇到鉴权失败统一拦截，先换票再补发原请求，用户全程无感。

为什么填久了会掉登录，点一下才掉反而少见

小程序页面可以长时间挂在后台，页面栈、报销单里已填的内容都还在，但登录态是独立计时的另一套东西。用户感觉“刚才还好好的”，实际是凭证在自己的时间轴上走到了尽头；页面没刷新，所以掉登录的那一刻才显得突然。

按 2026 年项目交付习惯，登录态有效期由后端定，常见区间从 2 小时到 7 天不等，也有做成 30 天的；微信侧用登录凭证换取的会话密钥由平台管理，不适合当成长期身份凭证一直存在前端。

• 凭证本身到点：接口返回鉴权失败，前端没有统一拦截，直接跳了登录页。
• 凭证被新登录顶掉：同一账号在另一台设备登录，服务端把旧票作废。
• 请求没带上票：本地缓存被清，或页面栈里旧页面还握着已经失效的那一份。

这三种现象长得像，排查方向完全不同，先分清再动手，通常能省掉一轮返工。

先分清三种“又跳回登录页”，排查方向不同

• 时间型过期：多个页面同时跳登录，时间点集中在用户停留 20 分钟以上之后。核对后端返回的有效期与本地记录的签发时刻是否一致。
• 顶号型失效：用户只在一个页面上被跳走，其他页面正常。核对服务端有没有单点登录或旧票作废逻辑。
• 丢票型失效：刷新一下就好，或者换个页面就正常。核对请求头有没有带凭证、页面里有没有缓存旧值。

一个可用的判断标准是：同一次操作里前后两个接口一个成功一个失败，基本可以排除凭证过期，往请求封装和并发方向找；反过来，失败集中在长时间停留之后，时间型过期的可能性更大。

一套能落地的三段续期框架

把登录态当一条时间线来管，而不是当成一个字符串存下来。下面这套分法在项目里比较通用，前端和后端各管一段，边界清楚，出了问题也容易定位。

1. 登录时就记下到期时间：后端返回凭证的同时给出有效期（秒），前端记录签发时刻；不要只在本地写死一个过期时间点，设备时间被改就会算错。
2. 请求前判断剩余时间：剩余时间低于阈值（经验区间 5 到 15 分钟）时，先静默刷新换新票，再发业务请求。这一步能覆盖大多数长停留场景。
3. 失败时统一拦截：接口返回鉴权失败，走全局拦截器，刷新凭证成功则重放原请求，刷新失败才清本地并跳登录页。

第 2 步和第 3 步是互补的。只做第 3 步，用户点了才救，会有明显顿挫感；只做第 2 步，又挡不住顶号和网络中断。第 3 步容易踩坑的地方是并发：多个请求同时失败时，刷新动作要串行化，后到的请求排队等第一次刷新的结果，而不是各自去换一张新票。

静默刷新和重新授权，怎么选不纠结

两者不是替代关系，而是覆盖不同场景。日常浏览、长表单填写、购物车停留，用静默刷新；涉及资金、身份变更、敏感信息的动作，加一道显式确认更稳。选择时可以看“打断一次操作的代价”和“被冒用的风险”哪个更高。

• 静默刷新：适合停留久、操作链路长的页面。代价是要处理并发与死循环，刷新接口本身不能走鉴权拦截。
• 重新授权：适合换设备、清缓存后回来、风控要求高的动作。代价是打断当前操作，长表单要配合本地暂存。
• 混合策略：平时静默，支付、改手机号、开票这类动作前再校验一次。多数电商与工具类小程序落在这一档。

工作量上，只补一层失败拦截并重放，常见区间是 1 到 2 人日；如果加请求前静默刷新和并发排队，常见区间会到 3 到 5 人日；若还要做刷新凭证落库、多端互踢、有效期可配置，常见区间会到 1 到 2 周。先把范围写进需求清单，再谈工期，比事后补账容易得多。

交付现场经验：报销单提交跳登录怎么压住

在项目里常见的情况是：一期预算紧、后端沿用现成框架、登录态默认两小时过期，前端也没有统一请求封装。用户在公司内网填了二十多分钟报销单，点提交那一刻跳登录，草稿没暂存，第二天只能重新填。后来补了两件事——先把请求封装补上统一拦截和静默刷新，并把刷新接口放进鉴权白名单；再把报销单关键字段做本地暂存，登录成功后回填；最后约定敏感提交前做一次票据校验。代价是增加前后端联调约 1 到 2 人日，后端要提供一个刷新接口和过期时间字段。结果：长停留提交不再明显掉登录，用户填了一半的内容也能回来。这类改造多数落在 1 到 5 人日的经验区间，取决于原请求层是否统一。

适用场景与边界

适合做续期的场景比较明确：登录后停留时间长、页面上有用户输入、流程跨多个页面，或者要求长期免密使用。这类业务里，登录态断一次，损失的是用户已经投入的时间和信任，代价远大于补一段刷新逻辑。

也有不必上或者不必做重的情况。纯展示类页面、每次打开只读内容的工具页，过期后静默重新登录一次就够了；五六分钟就能走完的一次性活动页，专门加一套刷新链路，反而多出一个并发点，还增加联调成本。

可以独立摘录的边界句是：如果业务里没有需要跨页面保留的用户输入，且重新登录本身是静默的，那么不专门做登录态续期，也不会明显影响体验。反过来，只要涉及表单、购物车、多步提交中的任意一项，续期就该放进需求清单，而不是等上线后补。

常见问题

小程序登录态一般设多久比较合适？

没有统一标准，常见区间是短效凭证 2 小时到 7 天，配合长效刷新凭证；设得太短续期频繁，设得太长又要靠服务端撤销机制兜底。

用户切到后台十几分钟再回来，也要重新登录吗？

不必。小程序切后台通常不销毁，是否掉登录取决于有效期而非切后台本身；回到前台补一次校验，比直接跳登录页体验更好。

静默刷新失败了，前端该怎么兜底？

先重试一次，并区分是网络问题还是凭证问题；网络问题提示稍后再试，凭证问题才清本地并跳登录，同时把用户填的内容做本地暂存。

同一账号在两台手机上登录，老的那台会被踢下线吗？

取决于服务端有没有做单点登录，平台本身不强制；需求里要写明是允许并存还是只留一台，否则上线后会被当成缺陷来回改。

跳回登录页后，用户填了一半的报销单还能找回来吗？

能，但要在开发阶段就做。常见做法是把表单内容暂存在本地缓存里，登录成功后回填；没做这一步，数据基本找不回来。

如果你手里的小程序已经有长表单、购物车或多步提交，建议先核对两件事：后端是否返回有效期、前端是否有统一的请求拦截层。这两件对齐了，再补静默刷新，通常一两次联调就能跑通。反过来，如果只是展示型页面且登录本身静默，把资源留给更影响体验的问题，收益更高。2026 年做交付，登录态续期更适合放进基础体验清单，而不是等用户投诉后再补。