原生 getter 仅作无副作用的只读性能快照出口，需协同 performanceobserver、轮询与上下文绑定实现长效监控；其核心价值在于解耦采集与暴露，而非执行异步或响应变化。
原生 Getter 本身不执行异步操作，也不自动响应状态变化，但它可以作为轻量、无副作用的“指标快照出口”，配合外部采集机制，构建长效、可响应的异步流性能监控视图。关键不在 Getter 做什么，而在于它怎么被设计和协同使用。
用 Getter 封装只读性能快照
Getter 不适合承担数据采集职责，但非常适合暴露已聚合的最新指标值。例如：
- 定义一个全局监控对象（如 PerfStore），内部用普通属性或 Map 缓存实时更新的指标，如
metrics.lcpTime、metrics.jsHeapMax - 在该对象上声明 Getter，如
get lcpTime() { return this.metrics.lcpTime || 0; }，访问时直接返回当前快照 - 所有真实采集逻辑（如 PerformanceObserver 回调、定时轮询）独立运行，仅负责更新
PerfStore.metrics，与 Getter 解耦
靠 PerformanceObserver 主动注入动态数据
Getter 静态被动，必须搭配浏览器原生事件通知机制才能“长效”。推荐监听以下 entryTypes：
- paint：捕获首次绘制（FP）、首次内容绘制（FCP），滚动/交互中忽略重复触发
-
largest-contentful-paint：每次 LCP 更新都写入
PerfStore.lcpEntry，GetterlcpElement可安全返回对应 DOM 节点 - longtask：主线程阻塞事件，比轮询更早发现卡顿；记录起始时间、持续时长，供后续分析
-
resource：过滤 duration > 3000 的慢资源，按
initiatorType（script/css/img）分类归因
绑定异步行为上下文防指标失真
脱离上下文的数字没有意义。单页应用中需将指标与路由、组件、请求等生命周期对齐：
- 路由跳转前打点
performance.mark('route-start')，跳转后立即performance.measure('route-load', 'route-start')，结果存入数组，GetteravgRouteLoad返回滑动平均值 - 封装 fetch 函数，在请求发起时自动标记
${url}-start，响应后打点并测量，聚合到PerfStore.apiDurations - 用户开始滚动时启动计时器，滚动停止 500ms 后检查最新 paint 条目，计算滚动期间帧率趋势
合理轮询低开销实时属性作补充
部分 performance API 属性响应快、开销低，适合有限频次轮询：
-
performance.memory（Chrome）：每 2–5 秒采样一次usedJSHeapSize，观察内存增长趋势 -
performance.timeOrigin：固定值，用于统一所有自定义打点的时间基线校准 -
performance.now()：虽非 getter，但所有耗时测量必须基于它，而非Date.now()
不复杂但容易忽略：Getter 是视图层，不是采集层；长效靠的是 Observer + 轮询 + 上下文绑定三者协同，而不是让 Getter 自己“变活”。
