不存在“html 函数”，html 是标记语言，不执行逻辑；高 cpu 占用100%源于 javascript 无限循环、频繁重排/重绘，或未优化的 css 渲染。
HTML 里根本没有“HTML 函数”
直接说结论：不存在“HTML 函数”，所以谈不上它让 CPU 占用 100%。HTML 是标记语言，不执行逻辑、不运行函数。你看到的高 CPU 占用，100% 来自 JavaScript（比如 setTimeout、requestAnimationFrame、无限循环、重绘/重排失控），或是浏览器渲染引擎对复杂 DOM/CSS 的持续计算（比如强制同步布局、频繁 offsetHeight 读取、CSS 动画未优化）。
常见触发 CPU 100% 的 JS 场景
以下代码片段看似无害，但极易在页面中静默引爆 CPU：
-
while (true) { }或递归没出口 —— 直接锁死主线程 - 在
scroll/resize事件里没节流，反复调用getBoundingClientRect()或修改style - 使用
innerHTML频繁拼接大量 DOM，触发多次重排（reflow） - Canvas 动画里忘了
requestAnimationFrame控制帧率，或在每帧里做大量计算 - 监听
input事件并实时发起未防抖的 API 请求 + 渲染
验证方法：打开 Chrome DevTools → Performance 标签 → 点录制 → 复现操作 → 停止后看火焰图里哪个 function 占满横向宽度，基本就是罪魁祸首。
CSS 和 DOM 也能拖垮 CPU
很多人忽略 CSS 对 CPU 的隐性消耗：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- 滥用
box-shadow、filter: blur()、transform: rotateZ()在滚动区域，导致浏览器被迫用 CPU 合成而非 GPU 加速 - 大量使用
:hover+ 复杂选择器（如div:nth-child(2n+1) .item:hover ~ .detail），悬停时触发布局计算 - DOM 节点数超 5000 且存在频繁
querySelectorAll或offsetParent遍历 - 设置了
will-change: transform但元素实际不动，反而让浏览器维持不必要的合成层
检查方式：DevTools → Rendering → 勾选 “Paint flashing” 和 “Layer borders”，滚动/交互时看是否大面积闪红或出现过多分层。
快速定位和缓解的实操步骤
别猜，按顺序做这四件事：
- 在地址栏输入
chrome://system/，查renderer_process_count和对应 PID 的 CPU 占用，确认是哪个标签页进程异常 - 打开该页的 DevTools →
Memory→ “Take heap snapshot”，对比两次快照，看Detached DOM tree是否持续增长（内存泄漏常伴高 CPU） - 临时禁用所有第三方脚本（用
Network面板右键“Block request URL”），再测 CPU —— 快速排除库问题（比如某些旧版moment.js在解析错误格式时会死循环） - 把疑似问题代码包进
setTimeout(() => { /* code */ }, 0)，观察是否从“立即卡死”变成“延迟卡顿”——能延后说明是同步阻塞，不是异步失控
真正难处理的，往往是多个小开销叠加：一次 getComputedStyle + 一次 appendChild + 一次 classList.toggle 连续调用，浏览器来不及合并优化，就变成了持续 100%。这种得靠 Performance 面板逐帧拆解，没法靠经验跳过。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
