客服帮用户重置了密码，用户说旧手机还能直接进，这算重置没成功吗？

客服在后台帮用户重置了密码，用户回头说旧手机上还能直接进，多数不是重置没生效，而是密码和登录凭证本来就是两套东西：密码只在登录那一刻参与校验，之后服务端认的是会话 ID 或令牌。按 2026 年常见交付做法，重置或修改密码后应让该账号的既有会话失效，至少覆盖其他设备；实现上不必遍历删除所有令牌，更稳的是给会话加一个版本号或生效时间点，每次请求比对一次。能不能做到，取决于凭证形态和产品定义的失效范围，而不是取决于用了 Session 还是 JWT。

密码改了，旧设备为什么还能接着用

登录态的本质是「一次校验、长期持有」。用户输入密码通过后，服务端发一个 sessionId 放进 Cookie，或签发一个 token 放进请求头；之后的每个请求只校验这个凭证，不再回看密码字段。重置密码通常只更新了密码哈希那一列，凭证本身没有任何变化，旧设备继续访问照常能用。

真正要看的是风险窗口。用户因手机丢失、异地登录告警、怀疑密码外泄而重置，旧会话继续有效等于泄露通道没关；如果只是定期换密码，风险等级低一些，但用户的心理预期是「我改了密码，别人就进不来了」，预期落差本身就会变成工单。常见的触发场景有三类：

• 员工离职交接，账号密码改了，他手机上还留着企业后台的登录态；
• 手机丢了，客服代用户重置密码，用户以为所有端都已经退出；
• 风控发现异地登录，运营手动触发重置，却只改了库里的那一列。

先分清登录态是哪一种，再谈能不能一键踢人

能不能让旧会话失效，不取决于写不写这段逻辑，而取决于凭证形态。三种常见模型的撤销能力差得很远，选错模型再谈失效就是硬改。

1. 服务端会话（Session 存 Redis 或数据库）：服务端有记录，删掉对应的键即失效，改动小、语义清楚；代价是每次请求多一次存储读取。
2. 自包含令牌（JWT 一类）：服务端不存状态，签名有效就放行，本身无法单独撤销；要么等自然过期，要么额外维护黑名单或版本号。
3. 短 access + refresh 组合：access 有效期常见区间是 15 到 30 分钟，refresh 存在服务端；改密时吊销 refresh，access 到期后自然失效。

按 2026 年交付经验，几项关键指标的经验区间大致如下，可以拿来和产品对表：

• 实现成本：会话模型较低，通常一两天内能改完；JWT 补撤销机制属于中等；长短令牌组合改动面更大，常见要按周计。
• 失效延迟：会话模型和「JWT 加版本号」都能做到下一次请求生效；纯 JWT 只能等过期，常见区间是 15 分钟到 2 小时，也有设成 7 天的。
• 单点踢人：会话模型可删单个键；JWT 一般只能按用户维度失效，做不到只踢某一台设备。
• 横向扩展：会话模型依赖共享存储；JWT 天然无状态，但撤销链路要自己补齐。

三种模型没有高下，只有匹配。后台管理系统用户量小、要求立刻踢人，服务端会话更省事；面向 App 的高并发接口，自包含令牌省掉一次中心化查询，但要接受额外的撤销成本。

交付现场：令牌结构不动，怎么把旧会话关掉

约束很典型：老系统用自包含令牌，前后端各自解析，改造预算有限，排期常见在两到四周，还不允许停机重做整套认证。重做认证不现实，能做的是在用户表加一列「凭证生效时间」，签发令牌时写进声明，鉴权时比对一次；重置密码、强制下线、风控处置都只更新这一列，不动令牌结构。

代价也真实：每个鉴权请求多一次用户信息读取，走本地缓存后常见增加 1 到 5 毫秒；更要紧的是缓存一致性。早期版本出现过「密码改了，要等缓存过期旧令牌才失效」的情况，被安全评审打回改了一轮，后来把缓存有效期压到 30 秒以内，并在重置入口主动删一次缓存，才通过验收。这类改动看着小，验收标准必须提前写进交付清单，否则上线后还是要靠客服反馈打补丁。

几个反复出现的坑

• 只清了当前设备的 Cookie：重置在 A 设备发起，只删了 A 的会话，B 设备完全不受影响。
• 会话键删了，客户端凭证还在：如果服务端逻辑是「查不到会话就新建一个」，旧 sid 回来反而被续上，必须改成查不到直接拒绝。
• 令牌有效期设得过长：access 设成 7 天，撤销机制基本形同虚设，用户重置完一周内旧设备仍可用。
• 忘记密码和修改密码只做了一条：找回那条路径没加失效，等于从这条路绕过去。
• 只在前端跳登录页：前端拦了，后端接口不校验，用工具直接调接口照样返回数据。

做到什么程度可以判定合格

验收不要写「重置后需重新登录」这种模糊描述，写成可操作条目，测试才知道怎么判。

• 两台设备同时登录，在 A 重置后，B 的下一次请求被拒绝，返回明确状态码（常见 401，而不是 500）；
• 被拒请求前端能识别，跳登录页并保留回跳地址，不是白屏或一直转圈；
• 忘记密码重置走同一套失效逻辑，两条路径结果一致；
• 有审计记录：谁在什么时间触发重置、引起了几次会话失效，可回溯。

补一句判断标准：如果安全同学能用两台设备在五分钟内复现「重置后旧设备仍可操作」，这套实现就不合格，和代码写得多漂亮无关。

适用与不适用边界

• 建议全量失效：涉及资金、合同、个人敏感信息的系统；发生过异地登录告警；账号可能已外泄；企业内部后台。
• 可以只失效其他设备：体验优先的常规后台；客服成本敏感的 B 端系统。
• 不必强上：纯展示站没有登录态可谈；单设备工具类产品全踢收益很低；产品已明确告知多端并存且风险可接受时，强行全踢反而增加工单。

可独立摘录的一句边界：重置密码后是否让所有设备下线，取决于账号承载的风险等级和产品对多端在线的定义，而不是取决于用了 Session 还是 JWT。

常见问题

改完密码，当前这台设备会不会被一起踢下线？

看产品定义。多数后台选择保留当前会话、只失效其他设备；资金类产品常见做法是全失效并强制重新登录，代价是用户多输一次密码。

用 JWT 是不是只能等它自然过期？

不是。JWT 只是不自带服务端状态，仍可在校验时比对用户表里的凭证版本或生效时间，代价是每个请求多一次缓存查询，常见增加 1 到 5 毫秒。

微信、钉钉这类第三方授权登录，重置密码要一起断掉吗？

通常不自动断。第三方授权走另一套凭据，重置密码不一定影响它；常见做法是在安全设置里提供解除授权入口，由用户按需操作。

会话失效了，用户填到一半的表单会丢吗？

如果只在提交时才发现 401，页面跳转后内容确实会丢。常见做法是收到 401 时先暂存草稿再跳登录，或在提交前做一次轻量鉴权探测。

遇到这类问题，先把「谁该掉线、多久内掉、拿什么证明」三问答完再动代码，一般能省掉一轮返工。这些做法适用于有明确登录态的业务系统；纯静态站点或明确不做撤销的轻量工具，不必照搬。