HTML本身没有函数，也不参与CPU温控或降频；高CPU占用源于JavaScript行为（如过度rAF、密集定时器、未节流事件等），而降频由硬件和系统级策略决定，浏览器无权干预且无法感知温度。
HTML 本身没有函数，也不参与 CPU 温控或降频——这是操作系统和硬件层的行为，和 HTML、JavaScript 甚至浏览器进程都无直接控制权。
为什么说“HTML 函数”不会触发温控降频
HTML 是标记语言，不执行逻辑，也没有运行时函数。你实际遇到的高 CPU 占用，通常来自：requestAnimationFrame 过度调用、setTimeout / setInterval 密集轮询、未节流的 scroll 或 resize 事件、Canvas 动画未限制帧率，或 WebAssembly 模块持续计算。
这些行为会让 JavaScript 引擎持续工作，导致浏览器渲染线程/Worker 线程满载，进而推高 CPU 温度——但降频决策完全由 CPU 的微码（microcode）和系统级温控策略（如 Linux 的 intel_pstate、Windows 的 ACPI Thermal Policy）做出，浏览器无权限干预。
浏览器能感知温度或主动限频吗
当前所有主流浏览器（Chrome、Firefox、Safari）均不提供 API 让网页读取 CPU 温度、风扇转速或当前频率。也没有标准接口通知页面“你被热节流了”。
立即学习“前端免费学习笔记（深入）”；
-
navigator.hardwareConcurrency只返回逻辑核心数，不反映实时负载或频率变化 -
performance.memory（非标准）仅在部分 Chrome 版本中提供内存信息，与温度无关 - Web API 中不存在
thermalState、cpuThermalThrottling或类似字段 - 即使使用
PerformanceObserver监听longtask，也只能推测主线程阻塞，无法区分是因热节流还是代码写法问题
真实影响性能的温控场景有哪些
当设备进入热节流（thermal throttling），CPU 频率下降，所有进程都会变慢，包括浏览器中的 JS 执行、样式计算、布局、合成等。但表现不统一：
- MacBook 在风扇狂转后，
requestIdleCallback的空闲时间可能大幅延长，甚至超时 - 某些 Windows 笔记本在降频时，
setTimeout(fn, 0)实际延迟可能从 ~1ms 延长到 10–50ms，导致动画卡顿 - 低端 Android 设备上，WebView 内的 Canvas 动画帧率可能从 60fps 掉到 20fps，且
performance.now()时间戳间隔变不稳定 - 频繁触发 GC 的页面在热节流下更容易出现长任务（>50ms），引发
Input delay报警
能做的实际优化建议
既然无法绕过温控，就该减少持续高压行为，让 CPU 有喘息空间：
- 用
requestIdleCallback替代密集setTimeout处理低优先级任务（如日志上报、非关键 DOM 更新） - Canvas 动画务必加帧率限制：检查
performance.now()差值，而非依赖requestAnimationFrame的自然节奏 - 监听
visibilitychange，页面隐藏时暂停所有定时器和动画（cancelAnimationFrame+clearTimeout） - 避免在
scroll中直接调用重排重绘操作；改用getBoundingClientRect()缓存 +transform触发合成层 - 对大型数组处理，拆成 microtask 分片（
queueMicrotask），避免单次执行 >10ms
热节流不是 bug，是硬件保护机制。真正容易被忽略的是：同一段代码在室温 25°C 下流畅，在 40°C 环境中可能连续触发长任务——测试时别只盯着新 MacBook，得在旧 iPad、散热差的 Chromebook 上也跑一遍。
