Angular 4+NgRx部署后IE11中sessionStorage令牌复用问题求助

我来帮你梳理下这个问题的排查思路和可能的解决方案——这种sessionStorage看似“不更新”的问题，在IE11和服务器部署场景下挺常见的，大概率不是sessionStorage本身的API问题，而是缓存、拦截器状态同步或者IE11的特殊行为导致的。

一、先确认sessionStorage的实际状态是否真的更新 #

别只看代码逻辑，直接在IE11里验证真实的存储情况：

• 执行登出操作后，打开IE11的F12开发者工具，切换到「存储」标签，找到sessionStorage，检查你的token键是否真的被删除或重置成新值了。
• 如果这里token确实已经更新/清空，但请求还是带旧token，那问题肯定不在setItem/getItem本身，而是拦截器、NgRx状态或者请求缓存的问题。

二、排查IE11的GET请求缓存问题 #

IE11对GET请求的缓存机制非常激进，部署到服务器后，很可能因为服务器没设置正确的缓存头，导致浏览器直接复用了之前带旧token的缓存请求：

• 打开F12的「网络」标签，观察重新登录后的API请求，看是否显示「从缓存中获取」的标识。
• 解决办法：要么在GET请求的URL后加随机参数（比如?t=${new Date().getTime()}）避开缓存，要么让后端给API接口设置Cache-Control: no-cache, no-store, must-revalidate的响应头。

三、检查Angular拦截器的token读取逻辑 #

很多人会犯一个错误：在拦截器的构造函数里读取一次token就缓存起来，而不是每次请求都重新读取sessionStorage：

• 错误示例（缓存了初始token，后续不会更新）：

constructor() {
  // 只在初始化时读一次，之后一直用这个旧值
  this.token = sessionStorage.getItem('token');
}

intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
  const authReq = req.clone({ setHeaders: { Authorization: this.token } });
  return next.handle(authReq);
}

• 正确写法（每次请求都重新读取最新的token）：

intercept(req: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
  // 每次请求时都从sessionStorage拿最新值
  const token = sessionStorage.getItem('token');
  let authReq = req;
  if (token) {
    authReq = req.clone({ setHeaders: { Authorization: `Bearer ${token}` } });
  }
  return next.handle(authReq);
}

四、确认NgRx状态的重置是否彻底 #

登出时除了清空sessionStorage，还要确保NgRx store里的用户相关状态（包括token）被完全重置：

• 检查登出action对应的reducer，是否把用户信息、token等状态全部置为null或初始值。
• 如果登出时有异步操作（比如调用后端登出接口），要确保异步操作完成后再跳转或允许重新登录，避免状态还没重置就发起新请求。

五、排查IE11的sessionStorage特殊行为 #

IE11的sessionStorage有一些已知的兼容性bug：

• 如果你的应用是在iframe中运行，IE11对iframe的sessionStorage处理可能异常，尝试直接在主窗口打开应用测试。
• 偶尔会出现sessionStorage在页面刷新后才会同步的情况，你可以试试登出后强制刷新页面（window.location.reload()），再重新登录看是否解决问题。

六、检查服务器端的会话保持问题 #

如果后端是结合Cookie会话来识别用户，而不是完全依赖token，那可能后端没正确销毁旧会话，导致新token请求还是关联到旧用户：

• 确认登出时是否调用了后端的登出接口，让后端销毁对应的会话。
• 观察请求的Cookie，看登出后Cookie是否被清空或更新。

内容的提问来源于stack exchange，提问作者Eduard Omusoru