大表单提交要跑两分钟，回来直接提示登录过期，续期是提前做还是等报了 401 再补？

多数情况下，续期不该等 401 回来再做。等请求跑完才收到 401，意味着这两分钟的计算和传输基本白做，重放还要再等一轮；但如果每个请求发出前都无条件续一次，短接口又会被多余的往返拖慢。判断依据不是习惯，而是这个请求预计要跑多久、能不能安全重放。按 2026 年常见交付经验，比较稳的分法是：秒级短请求交给 401 触发一次重放，分钟级长请求和上传类接口在发起前先看一眼剩余有效期，常见区间是剩余不足 5~10 分钟就先续，并且把重放严格限定在幂等接口上。至于把 token 有效期从 2 小时调到 24 小时，它只改变过期时刻，不改变过期瞬间发生什么。

为什么长请求上「收到 401 再续」代价特别大

短请求遇到 401 再重放，代价是一次额外往返，用户基本无感；长请求不是这样。两分钟的提交、几百兆的上传、几分钟才出的报表导出，共同特点是耗时可能远大于凭证的剩余寿命。请求发出去时凭证还有三分钟，跑完已经过期，服务端在鉴权这一层就拒了，前面做过的计算没有产出任何结果。

更麻烦的是请求体。上传类接口的请求体是流，一旦被消费，前端在浏览器里无法简单「重放」一次，常见做法只能整份重来。所以这类接口的重放成本不只是时间，还有流量和用户耐心，网络上行不稳的现场尤其明显。

• 幂等性：查询、导出这类重放一次不产生副作用；创建订单、提交审批重放一次可能生成两条记录，重放前必须带幂等键。
• 校验时点：服务端校验的是请求进入那一刻的凭证状态，长请求在传输途中过期，结果取决于网关在入口校验还是逐段校验，这一点要按实际链路核对，不能凭印象假定。
• 续期并发：几个长请求同时发现过期，同时去续期，续期凭证被一次用废，表现就是偶发登出。
• 重放次数：重放限定一次，失败就转兜底，否则会形成循环，把本来只是慢的请求变成打满服务端。

交付现场：上传到八成被弹回登录页

说一个具体的现场。某次交付里有个合同附件上传功能，单文件常见区间在 100~300MB，客户那边上行带宽不稳。上线后的反馈是：传到百分之七八十，页面跳回登录页，回来附件没了，得从头再传一遍。当时约束有三条：工期只剩一周，后端分片上传接口已经上线不能改，前端上传组件是第三方库、只暴露了少量钩子。

我们的做法是不动上传组件内部，在它外面包一层：开始上传前先看本地记录的凭证签发时间，剩余不足一个阈值就先静默续期，续期成功再启动上传，这个阈值按单次上传预计耗时定，经验区间落在 5~10 分钟；分片请求中途遇到 401 不直接跳登录，而是先登记已成功的分片序号，续期后从断点续传。代价是这层包装要单独维护分片状态，第三方组件升级时得重新核对钩子行为，而且断点信息只存在当前标签页，用户关掉页面仍然要从头来。

这件事之后的结论是：续期逻辑本身不难，难的是让每条重放路径都知道自己能重放到什么程度。判断这层做得够不够，不看有没有续期接口，而看长请求失败后用户要重做多少。

三种触发策略怎么比

下面三组都是经验区间，具体取值按业务敏感度和平台规范调整，不要当成标准答案。

• 策略一：只在 401 时续期并重放：前端改造常见 1~2 人日；适合以秒级查询为主、接口幂等的后台；代价是长请求和上传类接口会白跑一轮。
• 策略二：长请求发起前预判剩余有效期：改造常见 3~5 人日，取决于请求封装是否统一、上传是否分片；适合有长表单、大文件、报表导出的系统；代价是多一次续期往返，且阈值要调对，否则每个请求都在触发续期。
• 策略三：把有效期直接调到 8~24 小时：几乎零改造；代价是凭证泄露后的可用窗口同步变长，强制下线、离职回收权限更难处理，多端登录的回收逻辑也更绕。
• 可核对口径一：把访问凭证有效期临时改成 1 分钟，跑一次长请求，观察是中途被踢，还是续期后跑完，两种结果对应完全不同的修法。
• 可核对口径二：断网 30 秒后再恢复，长请求应表现为可重试的失败，而不是直接跳登录页。
• 可核对口径三：开三个标签页同时上传小文件，统计服务端续期接口调用次数，应接近一次而非三次。

适用与不适用边界

这套分档思路适合有登录态、页面停留时间长、存在分钟级请求的 Web 后台与移动端应用，比如合同录入、批量导入、附件上传、报表导出。不适合的情况也要说清楚：

• 不必上：纯内网、单人使用的运维小工具，操作几秒就结束，短效凭证加正常登出就够，再加预判续期属于过度设计。
• 要调整：涉及资金、审批、权限变更的操作，即便凭证没过期，也建议在提交前要求二次验证，而不是靠续期把时效问题绕过去。
• 不适用：以服务端渲染为主、几乎不发异步请求的老系统，续期没有触发点，重点应放在会话配置和登出回跳上。
• 要防：续期凭证放在能被页面脚本读取的位置，等于把长效钥匙放在门口；具体存放方式按平台官方文档和安全规范核对。
• 要留：无论选哪种策略，登出前先把表单草稿落到本地，登录回来再回填；这一步是体验底线，不是可选项。

常见问题

访问凭证只用 15 分钟，长请求是不是就跑不完了？

不会。跑不完的是凭证在途中过期又没有任何续期通道的情况；只要发起前预判剩余时间或中途续期，15 分钟不影响长请求完成。

提交前统一续一次，是不是就不用管 401 了？

不够。续期成功到请求结束之间仍可能过期，网络中断同样会返回失败；预判续期和 401 重放是互补的两层，不是替代关系。

上传到一半报了 401，能不能让服务端接着收后面的分片？

要看分片接口是否按凭证绑定了上传会话。常见做法是续期后带着原上传标识续传，但接口支持和超时窗口要按接口文档核对，不能默认可行。

把续期塞进请求拦截器，长请求会不会被拦住很久？

多一次往返，常见区间在几百毫秒内。若拦截器对每个请求都发一次，改成本地按签发时间算剩余时间，只在临近过期时才真正发续期请求。

回到最开始的问题：调长有效期不是不能做，但它解决的是多久过期一次，解决不了过期那一刻长请求怎么办。如果你的系统里已经有人抱怨传一半断了、报表导到一半被踢，先拿一个测试账号把凭证改成 1 分钟，跑一遍长请求，看是被踢回登录页还是续期后跑完，两种结果对应的改动量差得很远。