cpu性能弱时应优先使用轻量同步原生api：用getelementbyid而非queryselector，批量操作用documentfragment，纯文本更新用textcontent而非innerhtml，并依据navigator.hardwareconcurrency等运行时指标精准判定弱cpu设备。
CPU性能弱时，别用花哨的解析器——直接选轻量、同步、低开销的原生方案，否则页面一动就卡顿。
用 document.getElementById() 而不是 document.querySelector()
前者是浏览器内置的最快ID查找路径，底层直连哈希表；后者需解析CSS选择器字符串、遍历DOM树、匹配规则，CPU弱设备（如旧款Chromebook、ARM平板）上单次调用可能多耗 2–5ms。实测在 navigator.hardwareConcurrency 的设备上，频繁调用 <code>querySelector 容易触发主线程长任务（>50ms），导致滚动掉帧。
- 只在必须用类名/属性/嵌套结构时才用
querySelector，且避免写成div.container ul li a这类深度选择器 - 若需批量查同类元素，先用
getElementById拿到父容器，再调用.getElementsByTagName或.getElementsByClassName，比全量querySelectorAll快 3–8 倍
批量DOM操作前必用 document.createDocumentFragment()
CPU受限设备对重排（reflow）极度敏感。每次向真实DOM插入节点都会触发样式计算+布局+绘制流水线，而 DocumentFragment 是离线节点容器，所有操作不触发渲染，最后一次性挂载，可把多次重排合并为一次。
- 不要这样写：
for (let i = 0; i - 应该：
const frag = document.createDocumentFragment(); for (...) { frag.appendChild(item(i)); } list.appendChild(frag); - 注意：frag 不能被
querySelector查找，它没有实际渲染位置，仅作中转
改 innerHTML 为 textContent 处理纯文本
innerHTML 需完整解析HTML字符串、构建新节点、校验标签闭合、处理实体编码，CPU占用高；textContent 直接设置文本节点内容，无解析开销。在低频更新场景（如状态提示、计数器）中，后者响应快 10 倍以上。
- 适用条件：确认内容不含任何HTML标签，且不需要保留原有子节点结构
- 危险操作：用
textContent替换含子元素的容器，会清空全部子节点（包括事件监听器） - 替代方案：若需保留部分结构，用
element.firstChild.nodeValue = 'new text'直接改文本节点值
真正容易被忽略的是「CPU弱」的判定标准——不是看设备型号，而是运行时查 navigator.hardwareConcurrency 和 performance.now() 循环阻塞时间。很多所谓“优化”在四核设备上反而因额外判断逻辑拖慢速度，该砍的分支就得砍，别迷信配置开关。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
