performancenavigationtiming是只读性能快照，非定时工具；它不可控、不更新、仅反映真实导航行为，无法用于倒计时或动态ui计时，正确用途是计算navigationstart至domcontentloadedeventend等固定阶段耗时。
PerformanceNavigationTiming 不是“做导航计时”的工具，而是浏览器自动记录的一组只读性能指标——你无法手动启动、暂停或重置它，只能读取它反映的真实导航行为。
为什么不能用 PerformanceNavigationTiming 实现倒计时或定时逻辑
它和 setInterval 或 Date.now() 完全不是一类东西：前者是快照式诊断数据，后者才是可控的时间计算基础。
-
PerformanceNavigationTiming只在页面加载完成（load事件后）才稳定可用，且每个导航周期仅生成一个实例 - 它的所有字段（如
navigationStart、domContentLoadedEventEnd）都是时间戳，单位为毫秒，但彼此不可相减用于业务逻辑——因为它们来自不同阶段，且受缓存、重定向、跨域等影响，差值不等于“用户感知耗时” - 试图用它驱动 UI 倒计时（比如“距加载完成还剩 X 秒”）会失败：这些值在页面加载完就固定了，不会随时间更新
performance.getEntriesByType('navigation') 返回什么、怎么安全取值
这是获取 PerformanceNavigationTiming 实例的唯一标准方式。注意返回的是数组，即使只发生一次导航，也要取 [0]。
- 必须等
load事件触发后调用，否则可能为空；DOMContentLoaded阶段调用大概率拿不到完整数据 - 要加判空和类型检查：
if (entries.length && 'navigationStart' in entries[0])，避免在某些旧版 Safari 或 iframe 场景下访问undefined属性报错 - 常见误用：
performance.timing已被废弃，不要混用；performance.getEntriesByType('navigation')是当前唯一推荐路径
真正需要“导航过程计时”时，该用什么
如果你的目标是向用户展示加载进度、统计首屏耗时、或做 A/B 测试对比，PerformanceNavigationTiming 提供的数据足够，但得配合正确使用时机和上下文。
- 首屏关键指标直接取：
entry.domContentLoadedEventEnd - entry.navigationStart（注意单位是毫秒，需除以 1000 显示秒数） - 想监控资源加载瓶颈？优先看
entry.fetchStart和entry.responseEnd，而不是自己用Date.now()打点——后者没考虑 DNS、TCP、SSL 等底层延迟 - 服务端渲染（SSR）效果评估，重点比对
entry.responseStart和entry.domContentLoadedEventStart的差值：差值越小，说明 HTML 解析越快，SSR 利用越充分 - 别忽略
entry.type：值为'reload'或'back_forward'时，很多字段（如redirectStart）为 0，直接参与计算会导致偏差
最容易被忽略的是：你以为拿到的是“用户打开页面到可交互”的时间，其实它不包含 JS 执行耗时（比如 React hydration）、也不包含第三方脚本阻塞的影响——那些得靠 PerformanceObserver 监听 longtask 或自定义打点来补全。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
