CPU Throttling 是浏览器开发者工具提供的运行时调试能力，用于模拟低端设备性能瓶颈，通过降低主线程调度优先级和执行速度来复现卡顿、长任务等问题，而非 JavaScript 自身触发的限速机制。
JavaScript 本身不能直接触发 CPU 限速，CPU Throttling 是浏览器开发者工具提供的**运行时调试能力**，用于模拟低端设备的计算性能瓶颈，帮助你在本地复现卡顿、长任务、渲染掉帧等问题。它不改变 JS 代码逻辑，而是降低浏览器主线程的调度优先级和执行速度。
如何在 Chrome / Edge 中启用 CPU Throttling
这是最常用且效果最接近真实弱机体验的方式：
- 打开 DevTools（F12 或 Cmd+Opt+I）→ 切换到 Performance 或 Rendering 标签页
- 点击右上角 ⋯ → More Tools → Rendering，勾选 CPU Throttling（部分版本需先点 Performance 面板右上角 ⚙️ → CPU Throttling）
- 下拉选择档位：2× slowdown（较轻）、4× slowdown（常用）、6× slowdown（强模拟低端 Android）
- 刷新页面或手动触发交互，观察 JS 执行时间（如 Long Tasks）、FPS 下降、布局抖动等表现
为什么不用 JS 自己“限速”
用 setTimeout 或 while(Date.now() - start < 10) 等方式人为拖慢 JS，并不能真实模拟低端设备问题：
- 它只是延长单次执行时间，但不会放大重排/重绘开销、内存压力或事件循环拥塞
- 无法反映 V8 引擎在低频 CPU 上的编译延迟（如 TurboFan 优化失败）、GC 频率升高、JIT 失效等底层行为
- 移动端 WebView（如 Android X5、iOS WKWebView）的引擎行为与桌面 Chrome 不同，仅靠 JS 模拟毫无参考价值
配合 Throttling 的有效验证手段
单开限速不够，要结合可观测指标才能定位真瓶颈：
- 在 Performance 面板录制操作，重点关注 Main 线程中的 Long Tasks（>50ms） 和 Layout/Update Layer Tree 耗时
- 开启 Rendering → FPS Meter，观察是否频繁跌破 30fps，尤其在 scroll/touchmove 期间
- 使用 Memory 面板录制堆快照，对比限速前后 DOM 节点数、监听器数量、闭包引用是否异常增长
- 在代码中插入
performance.mark('start'); … performance.measure('task', 'start');，用 Performance > Timings 查看实际耗时分布
更贴近真机的补充做法
CPU Throttling 是桌面端调试起点，但要覆盖真实移动场景，还需组合其他限制：
- 网络限速：DevTools → Network → Throttling 选 Slow 3G 或自定义（带高延迟），测试 JS 加载、懒加载、资源竞争
-
禁用硬件加速：启动 Chrome 时加参数
--disable-gpu --force-cpu-draw（适用于排查 WebGL/Canvas 渲染卡顿） -
真机远程调试：Android 连 USB 启用 USB debugging，Chrome 访问
chrome://inspect；iOS Safari 开启 Web Inspector 后用 macOS Safari 远程调试——这才是最终验真环境
