html无法直接测温，navigator.hardwareconcurrency仅反映逻辑核心数，performance.now()仅返回时间戳，二者均不能测量温度；真实发热源需通过devtools性能面板定位长任务、布局重排、gpu合成等高负载行为。
HTML 本身没有“根据硬件发热量筛选函数工具”的机制——发热量是物理现象，浏览器和 JavaScript 无法直接读取 CPU/GPU 温度传感器数据。所谓“按发热量筛选”，实际是通过间接指标识别高功耗行为，再规避或优化对应 API 的使用。
为什么 navigator.hardwareConcurrency 和 performance.now() 不能测温度
这两个 API 常被误认为能反映发热，但它们只提供线索，不等于温度：
-
navigator.hardwareConcurrency返回逻辑处理器数量，仅说明并行潜力，高核心数设备未必更热；低核心数设备若持续满载，反而更容易升温 -
performance.now()测量的是主线程时间戳，长任务（>50ms）确实常伴随 CPU 占用飙升，但无法区分是 JS 计算、布局重排还是垃圾回收导致的发热 - 浏览器出于安全限制，完全禁止访问硬件温度传感器（如 Intel RAPL、ACPI thermal zone），连 WebAssembly 或 Worker 都不可达
哪些 HTML/JS 行为真正容易引发局部过热
不是所有“重”操作都等价发热。实测中以下行为在轻薄本、平板或旧手机上最易触发风扇狂转或降频：
-
requestAnimationFrame中频繁调用getBoundingClientRect()或offsetHeight：强制同步布局计算，CPU+GPU 双吃紧 - 未节流的
scroll或mousemove回调里执行 DOM 查询（如querySelectorAll）：滚动一屏触发数百次重排重绘 -
Canvas 2D在requestAnimationFrame中反复clearRect()+fillRect()绘制千个以上小矩形：显存带宽打满，GPU 温度直线上升 - 滥用
CSS 3D transform（尤其配合will-change: transform）：强制图层提升，iOS Safari 和部分 Android WebView 会绕过 GPU 优化路径，退化为 CPU 合成
如何用 DevTools 快速定位“发热源”函数
不靠猜，用 Chrome/Edge Performance 面板捕获真实负载：
- 录制时勾选 “Screenshots” 和 “Web Workers”，否则看不到帧率跌落与 Worker 线程占用的关联
- 重点看
Main线程火焰图中连续 >30ms 的黄色/红色块：Layout高表示样式计算或重排，Paint高表示绘制压力，Scripting高才可能是 JS 函数本身问题 - 右键长任务 → “View call stack”，直接定位到具体函数名（如
renderTableRows或updateChart），而非笼统归因于“for 循环” - 对比开启/关闭某功能后的
GPU Process区域高度：若开启transform: rotateZ(0.1deg)后 GPU 占用从 10% 涨到 90%，说明 CSS 触发了非预期合成
Worker 也不能无脑用——它可能让 CPU 更烫
把 filter() 搬进 Worker 看似卸载主线程，但若数据量不大（
- Worker 初始化本身要消耗约 4–6MB 内存，短时任务（
- 主线程向 Worker 传大数据用
postMessage(data, [transferList])，漏写transferList就变成深拷贝，内存翻倍且 GC 延迟升高 - 实测发现：在 M1 MacBook 上，单次
Uint32Array.sort()耗时 8ms，放 Worker 反而总耗时 15ms（含序列化+传输+反序列化） - 真正该进 Worker 的是：模糊搜索（需遍历百万字符串）、位图运算、Trie 树构建——这些才是稳居 50ms+ 的“发热大户”
发热不是玄学指标，而是可复现的性能副作用。盯住长任务、GPU 占用、内存增长这三项，比任何“温度估算函数”都管用。一旦发现某段代码在低端机上风扇狂转，优先检查它是否在每帧都触发布局、是否绕过了浏览器的合成优化、是否把小任务塞进了大 Worker——而不是去找一个根本不存在的 navigator.temperature。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
