用户退出登录后浏览器里还留着旧数据，响应头怎么要求清除

用户退出登录后浏览器里还留着缓存和存储，响应头怎么要求清除，靠的是一个由服务端发出的清除信号，而不是页面里的脚本自己删。这个信号就是 Clear-Site-Data 响应头：服务端在退出接口的应答里把它带上，等于把「请清掉哪几类浏览数据」的指令交给客户端，由浏览器按项执行本地清理。它能表达的只有两件事：清哪些类数据、清到哪个范围，其余看客户端是否配合。

退出登录为什么要主动清一遍

登录态由服务端签发：建立会话时下发凭证，注销时服务端把凭证作废。浏览器侧记的是另一套账，页面、脚本、接口应答会进缓存，业务代码也可能把中间结果写进本地存储，这些内容与会话没有绑定关系，不会因为会话失效而自动消失。

于是出现错位：用户点了退出，服务端已经翻篇，旧数据还摊在设备上。下一个人用同一台机器同一个浏览器打开站点，哪怕拿不到新会话，也可能从残留里看到上一位的页面内容。主动清一遍，就是把两侧对齐。

具体到站内，登录态由 JWT 承载，服务端注销与会话失效是一侧的事，浏览器本地的缓存与存储要靠这个响应头配合清一遍。就这两点，不引申出别的期待。

能清哪几类本地数据

指令按项给出，一条应答里可以同时列多项，客户端只处理被列出的那些类。常见分项与各自管的东西如下。

列少了收尾不干净，列多了会误伤用户打算留着的东西。

为什么只在加密连接里生效

这条能力只在安全上下文里可用，落到部署上就是应答必须走加密连接，也就是 HTTPS。明文连接里带上这个头，浏览器不会照做，清理动作也不会发生。

原因不难理解：它要求的是删本地数据，影响面很大，浏览器不接受可能被中间环节篡改或伪造的信号。结论是先确认站点整体走加密入口，再讨论这个头有没有生效；测试里加了却没起作用，先查访问路径是不是加密连接。

清除范围到来源还是到注册域

不同分项的落点不一样，这是最容易混淆的一处。

cookies 的影响面是整个注册域，包含它下面的子域。主域下多个子系统共用同一套登录凭据时，一条指令就能把它们一并覆盖，不需要挨个域名分别处理。

storage 清的是响应对应来源的本地存储。来源由协议、主机、端口共同确定，换个主机或换个协议就是另一个来源，不会被连带清理。

差别在这里有实际意义：想收干净凭据，靠的是注册域那一层的范围；想清准本地存储，就得让带这个头的应答出现在真正写入数据的来源上。

公共设备上为什么更值得加这一层

私人设备上的残留主要影响使用者自己。公共设备不同：前台的平板、车间共用的终端、***流用的同一台机器，上一位退出后浏览器不归他管，下一位直接接手同一份本地数据。这类场景里，服务端单方面作废会话收不干净前一个人的痕迹，客户端这一层的清理补上了缺口。

也要看清它靠不住的地方：服务端只能发信号，清不清、清得干不干净由客户端执行，不配合的浏览器可以完全忽略这条指令，不同浏览器对不同分项的支持程度也不一样。自 2023 年 9 月起这项能力在浏览器里普遍可用，但普遍可用不等于各分项表现一致。

所以它替代不了服务端的会话撤销。作废凭证、吊销记录、清理服务端侧的状态仍要在服务端做完，这一层是收尾，不是安全边界本身。

常见问题

问：退出接口只把会话作废，不返回这个头，会有什么后果？ 答：服务端侧干净了，但浏览器在访问期间攒下的缓存与本地存储仍留在设备上，换人使用时这些残留可能被下一个看到的人翻出来。

问：能不能只在退出这一刻下发？ 答：可以，它做的是删除动作，代价由客户端承担；放在确认要结束会话的接口上语义清楚，也不会在正常浏览途中清掉用户正在用的数据。

问：清了 cookies 这一项，等于本地数据都清完了吗？ 答：不等于。cookies 覆盖的是注册域下的凭据，本地存储属于另一分项，缓存同样另算，要分别列出才有效果。