APP频繁要求重新登录，是影响用户体验的常见痛点。面试中关于Token过期处理的问题，实则考察对系统安全与用户体验平衡的思考。本文将深入剖析三种主流的Token自动续期方案，从前端主动刷新到后端滑动续期，再到当前最安全的双Token机制，助你理解其核心原理、适用场景与利弊权衡。
智能速览
面试中Token过期问题，旨在考察自动续期方案的设计能力。
前端定时刷新实现简单，但将核心逻辑暴露于客户端，安全性不足。
后端滑动窗口由服务端主导，但攻击者可通过持续请求维持Token有效性。
双Token机制是当前主流，通过长短Token分工，兼顾了高安全与无感体验。
Access Token短期访问，Refresh Token长期刷新，两者协作完成续期流程。
精华内容
面对Token过期这一技术难题，业界已沉淀出几种成熟的解决方案。它们在实现复杂度、安全性与用户体验上各有侧重，如何选择取决于业务的具体需求。
前端主动刷新
前端定时刷新是一种由客户端主导的续期策略。前端通过设置一个定时器，周期性地检查本地存储的Token剩余有效时间。当剩余时间低于预设的阈值时，例如在2小时的有效期内只剩下20分钟，前端便会主动调用后端的专用刷新接口。
后端收到请求后，会对当前Token的合法性进行校验。若校验通过，便生成一个新的Token并返回给前端，前端随即更新本地存储，实现无感续期。若Token不合法，则直接返回401状态码，强制用户重新登录。此方案逻辑清晰，实现成本较低，能保证在页面不关闭时持续有效。然而，续期的核心逻辑完全依赖前端，带来了显著的安全隐患，仅适用于对安全性要求不高的系统。
后端滑动续期
滑动窗口方案将续期的主导权交给了后端。前端每次发起业务请求时，只需正常携带Token。后端网关层的拦截器会拦截所有请求，并对Token进行校验。
如果Token非法，直接返回401。如果Token合法，服务端会查询该Token的最后访问时间与原始有效期，并计算其剩余有效时长。一旦判断Token即将过期，比如在2小时有效期内仅剩20分钟，后端会自动生成新Token并随响应返回，前端负责更新。若Token未到续期阈值，则正常处理业务请求。这种方案虽然逻辑后移，但安全漏洞依旧存在：攻击者只需在被盗的Token过期前持续发起请求，便可不断“滑动”其有效期，使其永久有效，因此同样不适用于高安全需求的场景。
双Token保障
双Token机制是当前业界公认的最优解，它在安全性和用户体验之间取得了绝佳平衡。该方案引入两种角色分工明确的Token：Access Token和Refresh Token。
Access Token有效期极短，通常为30分钟至2小时，专门用于调用业务接口，是访问服务的“临时通行证”。Refresh Token有效期则很长，可达7至30天，它的唯一作用是获取新的Access Token，不参与任何业务鉴权。用户登录成功后，会同时获得这两个Token。当携带Access Token的请求因过期而收到401响应时，前端会自动使用Refresh Token调用刷新接口，换取新的Access Token后，立即重试刚才失败的请求。整个过程对用户完全透明。只有当Refresh Token也失效或过期时，用户才会被引导至登录页。此方案安全性极高，即使Access Token泄露，其有效期也极短，能将损失降到最低，但实现逻辑相对复杂，开发周期较长。
综上，Token续期方案从前端简单实现到后端智能滑动，最终演变为双Token机制，清晰地展现了技术为了平衡安全与体验而不断迭代的路径。双Token方案虽然复杂，却为现代应用提供了最可靠的保障。在实际项目中，你会如何根据业务的安全等级和开发资源，来选择最合适的续期策略呢？
