PerformanceObserver 可间接捕获页面级内存与 CPU 压力趋势：Chrome/Edge 支持 memory 指标（需启动参数）和 navigation duration 推断主线程阻塞，跨浏览器仅能依赖 performance.now() 与 requestIdleCallback 组合估算空闲时间。

用 PerformanceObserver 捕获内存与 CPU 使用率（Chrome/Edge 有效）

浏览器原生不提供直接读取系统级 cpu 或内存占用的 api，performanceobserver 是目前唯一能稳定拿到部分运行时资源指标的途径，但仅限于当前页面进程的近似值，不是操作系统全局数据。

它能监听 "measure" 类型的自定义性能条目，配合 Chrome 的私有指标（如 memory、navigation），可间接反映压力趋势：

• performance.memory.usedJSHeapSize / performance.memory.totalJSHeapSize 可算 JS 堆使用率（注意：仅 Chrome，且需启用 --enable-precise-memory-info 启动参数，普通网页默认不可用）
• performance.getEntriesByType("navigation")[0].duration 配合高频采样，能推断主线程阻塞程度（非 CPU，但相关）
• 真正跨浏览器可用的只有 performance.now() + requestIdleCallback 组合：若空闲时间持续

侧边栏进度条 DOM 结构和更新频率怎么设才不卡

进度条本身是纯 CSS <div> + <code>width 百分比控制，但更新太勤会触发重排，尤其在低配设备上反而拖慢监控本身。

实操建议：

• 采样间隔不低于 1000 ms；低于 500 ms 时，Chrome DevTools 的“Rendering”面板会明显显示 Layout 强制同步
• 用 requestAnimationFrame 包裹 DOM 更新，而非直接赋值 style.width；避免在 setTimeout 回调里连续改多次
• 进度条容器必须设 will-change: transform 或用 transform: scaleX() 替代 width，减少重排开销

为什么 navigator.hardwareConcurrency 不能当 CPU 占用率用

navigator.hardwareConcurrency 返回的是逻辑 CPU 核心数（比如值为 8），不是实时负载。把它当“100% = 8 核全满”来映射进度条，会导致严重误判——单核满载时进度条才到 12.5%，用户根本感知不到压力。

更糟的是，这个值在 iOS Safari 上长期返回 1（即使 A17 Pro），完全不可靠。

替代思路：

• 用 Worker 跑一段固定计算量的循环（如 for (let i = 0; i ），测执行耗时；对比空闲时基线值，得出相对负载
• 只在桌面 Chrome/Edge 上依赖 performance.memory，其他环境降级为“连接状态 + 长任务计数”（用 PerformanceObserver 监听 "longtask"）

部署时容易被忽略的权限和兼容性断点

本地开发跑通不等于上线能用。两个硬性限制常被跳过：

• Chrome 120+ 要求页面必须是 https 或 localhost 才允许访问 performance.memory，HTTP 页面直接报 TypeError: Cannot read property 'memory' of undefined
• Safari 完全不支持 performance.memory 和 "longtask" 类型监听，iOS 上连 hardwareConcurrency 都是摆设，必须有降级 fallback（例如隐藏进度条，只显示文字提示 “监控不可用”）
• 某些企业内网代理会拦截 PerformanceObserver 的初始化，表现为 observer.observe() 无报错但无回调，加个 console.log("observing...") 在调用后能快速定位

真实环境里，超过三分之一的用户看不到任何数值，不是代码写错了，而是浏览器根本不给这个门开一条缝。