浏览器 Cookie Store API 怎么监听登录态变化：change 事件、页面刷新与降级处理

单页应用里，退出登录往往不是一个按钮的问题：导航栏、个人菜单和当前页面都要同时知道会话已经失效。继续用 document.cookie 轮询，既要自己比较旧值，又容易把刷新时机分散到多个组件。支持 Cookie Store API 的浏览器可以直接监听 cookieStore 的 change 事件，再把状态收敛到一个刷新函数里；不支持时则保留一次初始读取和低频兜底。

Cookie Store API 解决的到底是哪一类问题

如果登录态只在页面首次加载时读取，用户在另一个标签页退出后，当前页可能还显示着“已登录”。Cookie Store API 把 Cookie 读取和变化通知做成异步接口，页面可以在状态变化后重新拉取用户信息，而不是让每个组件都猜“什么时候该更新”。

它监听的是当前脚本可见的 Cookie 变化，不是浏览器扩展的全量 Cookie 监控。服务端设置了 HttpOnly 的会话 Cookie 仍不能被页面脚本读取值；页面只能根据可见信号重新请求一个返回 401 或匿名状态的用户接口。

最小监听写法：事件只负责触发一次状态同步

先把“刷新当前用户”写成可重复调用的函数，再接入事件。函数内部不要直接修改多个组件的局部状态，否则同一轮变化可能出现导航栏更新了、内容区还没更新的半成品。

const userState = {
  loading: false,
  user: null,
  lastSync: 0,
};

let refreshTimer;

async function refreshSessionUser() {
  if (userState.loading) return;
  userState.loading = true;
  try {
    const response = await fetch("/api/me", {
      credentials: "include",
      cache: "no-store",
    });
    userState.user = response.ok ? await response.json() : null;
    userState.lastSync = Date.now();
    renderAccountArea(userState.user);
  } finally {
    userState.loading = false;
  }
}

function scheduleSessionRefresh() {
  clearTimeout(refreshTimer);
  refreshTimer = setTimeout(refreshSessionUser, 80);
}

if ("cookieStore" in window) {
  cookieStore.addEventListener("change", scheduleSessionRefresh);
}

refreshSessionUser();

这里的 80 毫秒只是把一小段连续变化合并成一次 UI 更新，不是登录安全窗口。真正的权限判断仍由服务端接口完成。可见成功状态是：退出登录后，/api/me 返回匿名结果，导航栏和受保护内容同时切换到未登录状态。

不要把 change 事件当成 Cookie 值监控器

最容易踩的坑是只绑定事件却不做首次读取。页面打开时 Cookie 可能早已存在，不会因为“已经存在”再发一次变化通知，所以初始化同步必须独立执行。

同名 Cookie 替换为什么可能没有通知

CookieChangeEvent 的语义重点是创建和删除。按照 MDN 的说明，如果新 Cookie 与旧 Cookie 的名称、域名和路径相同，只是值被替换，不会触发一次对应的 change 事件。依赖“每次续期都通知页面”的方案因此不稳妥。

更安全的设计是把 Cookie 事件当作“可能需要刷新”的提示，而不是认证事实。真正调用受保护接口时仍带上 credentials: "include"，收到 401 后清理本地用户状态；这样即使续期没有产生事件，业务权限也不会由前端旧缓存决定。

兼容处理：事件驱动和回退路径要共用同一个刷新函数

Cookie Store API 在支持的安全上下文中才可用。能力检测不要只看浏览器品牌，直接检测接口是否存在；回退路径也不要复制一份完全不同的登录逻辑。

const supportsCookieStore = "cookieStore" in window;

if (supportsCookieStore) {
  cookieStore.addEventListener("change", scheduleSessionRefresh);
} else {
  window.addEventListener("visibilitychange", () => {
    if (document.visibilityState === "visible") {
      refreshSessionUser();
    }
  });
}

window.addEventListener("session-expired", refreshSessionUser);

如果产品必须覆盖更老的环境，可以在回退路径增加一个较长间隔的轮询，但要给请求设置并发保护和停止条件。页面隐藏时停止轮询，重新可见时做一次同步，通常比后台标签页一直发请求更合适。

上线前检查四个可见结果

1. 在 HTTPS 页面打开控制台，确认 "cookieStore" in window 返回预期结果。
2. 从当前页触发退出登录，确认用户接口返回匿名状态，导航栏和内容区一起更新。
3. 在另一个标签页完成退出，再切回当前页，确认事件刷新或可见性回退能收敛状态。
4. 模拟服务端把同名 Cookie 替换为新值，确认页面仍以受保护接口的返回结果为准。

这四步能区分“事件没有触发”“事件触发了但刷新被并发保护跳过”“接口仍返回旧缓存”三类问题。排查时先看网络面板里的 /api/me，不要只盯着控制台有没有打印事件对象。

常见问题

Cookie Store API 能读取 HttpOnly 登录 Cookie 吗？

不能。页面脚本不能读取 HttpOnly 的值，登录态应通过带凭据的业务接口确认；Cookie Store 事件最多作为触发刷新信号。

为什么页面刚打开没有 change 事件？

已有 Cookie 不会因为页面初始化而自动产生变化通知。首次进入必须主动请求当前用户状态。

非 HTTPS 页面能使用 cookieStore 吗？

不要假设可以。该能力要求安全上下文，在本地开发和线上环境都应通过能力检测确认，并准备回退路径。

事件回调里直接刷新多个组件可以吗？

不建议。把回调收敛到一个可幂等的用户状态同步函数，再由统一状态驱动组件渲染，才能避免半更新和重复请求。

结尾：把事件当提示，把接口当裁判

Cookie Store API 适合缩短登录态变化到界面更新之间的路径，但它不替代服务端认证，也不能覆盖所有 Cookie 替换细节。事件触发刷新、接口确认权限、旧环境走回退，这三层职责分开后，单页应用的登录状态会更容易测试，也更容易在浏览器能力变化时维护。