performance.navigation 已被废弃，chrome 85、firefox 80 起完全移除，应改用 performance.getentriesbytype('navigation')[0].type 判断导航类型，如 'reload' 表示刷新。
performance.navigation 已被废弃，现代浏览器中不应再使用它来判断页面刷新或清理缓存。
为什么 performance.navigation 不可用
从 Chrome 85、Firefox 80 等版本起，performance.navigation（及其 type 和 redirectCount 属性）已被完全移除。调用它会返回 undefined 或抛出异常。W3C 标准已用 PerformanceNavigationTiming 接口替代，但该接口也不直接暴露“是否刷新”这一语义，而是提供更底层的导航类型信息。
替代方案：用 performance.getEntriesByType('navigation')
通过获取当前导航条目，检查其 type 字段可间接判断用户行为：
-
'navigate'：正常跳转（如点击链接、location.href 跳转） -
'reload'：明确由刷新触发（F5、Ctrl+R、右键刷新、地址栏回车后点刷新图标） -
'back_forward'：前进/后退（含 bfcache 恢复） -
'prerender'：预渲染（较少见）
示例代码：
const navEntry = performance.getEntriesByType('navigation')[0];
if (navEntry && navEntry.type === 'reload') {
console.log('页面是通过刷新加载的');
// 此处可执行缓存清理逻辑
}
清理缓存不能靠 JavaScript 主动“清空”
JS 无法真正清除 HTTP 缓存、Service Worker 缓存或磁盘缓存。所谓“清理”，实际是规避缓存策略，常见做法包括：
-
资源加时间戳或随机参数：如
fetch('/data.json?t=' + Date.now()) -
设置 fetch 选项：使用
{ cache: 'no-store' }或{ cache: 'reload' } -
禁用 Service Worker 缓存逻辑：在 SW 的
fetch事件中对特定请求跳过 cache.match - 强制重新加载时跳过缓存：用户按 Ctrl+F5（hard reload）时浏览器自动忽略所有缓存，但 JS 无法模拟该行为
更可靠的刷新检测组合建议
单靠 Performance API 不够健壮，可结合以下方式提高准确性：
- 监听
beforeunload存标记（如sessionStorage.setItem('wasUnloaded', '1')），在页面加载时读取并清除——若存在且为新页面，则大概率是刷新 - 对比
document.visibilityState和performance.timeOrigin变化趋势（适用于 SPA 场景） - 服务端配合：在响应头中添加自定义标识（如
X-Nav-Type: reload），需后端识别 User-Agent 和请求特征（如无 Referer、有 Cache-Control: no-cache 等）
注意：没有 100% 准确的方法，应根据业务容忍度选择组合策略。
