单核CPU上DOM操作应优先用document.getElementById（快2–4倍）、textContent（避免innerHTML重排）、事件委托（减少监听器）、读写分离（防强制同步布局）。
document.getElementById 比 querySelector 快 2–4 倍
单核 CPU（如 Intel Celeron N305、AMD Athlon Silver 3050U）执行 DOM 查询时，document.getElementById 是最轻量的选择。它跳过 CSS 选择器解析，直接哈希查表，无正则、无树遍历；而 document.querySelector 需完整解析选择器字符串、匹配规则、遍历子树，单核下耗时明显更高。
实操建议：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 只要目标元素有
id，一律用document.getElementById，别图省事写querySelector('#my-id') - 动态生成的元素，优先加
id而非 class，为后续快速获取留路 - 旧版 IE8 及以下不支持
querySelector，但getElementById从 IE5 就存在，兼容性零成本
textContent 替代 innerHTML 处理纯文本
在单核设备上，innerHTML 不仅要解析 HTML 字符串，还要重建 DOM 子树、触发重排（reflow），一次赋值可能卡顿几十毫秒；而 textContent 是纯文本写入，不触发解析与布局，开销极低。
常见错误现象：循环中用 el.innerHTML += 'item' 渲染列表，CPU 占用飙高、滚动卡顿。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 只更新文字内容时，强制用
el.textContent = newText - 需插入 HTML 片段时，先用
document.createDocumentFragment()构建离线节点，再一次性appendChild - 避免在
for循环里反复读写innerHTML——这是单核上的“性能杀手”组合
事件委托 + matches 避免大量监听器
单核设备内存小、JS 引擎调度压力大，为每个按钮单独绑 addEventListener 会快速堆积监听器，增加事件分发开销和内存占用。而事件委托把监听收口到父级，靠 event.target.matches('.btn-save') 判断目标，大幅降低主线程负担。
使用场景：表格行操作、动态增删的表单项、无限滚动列表。
实操建议：
- 统一绑定在
document.body或最近公共父容器上，别滥用document - 匹配选择器尽量简单，
'.submit-btn'比'div.form > button[type="submit"]'快得多 - 移除委托监听时，确保调用
removeEventListener并传入相同函数引用，否则泄漏
避免 offsetHeight / getBoundingClientRect 触发强制同步布局
单核 CPU 对同步布局计算（forced synchronous layout）极其敏感。offsetHeight、getBoundingClientRect() 这类读取布局的 API，若在样式写入后立即调用，会强制浏览器中断当前 JS 执行、回退到上一帧完成 layout，造成严重卡顿。
性能影响：实测在赛扬 N305 上，连续 10 次 offsetHeight 读取可导致主线程阻塞 80ms+。
实操建议：
- 把所有布局读取操作集中到一起，写在所有样式修改之后（“读写分离”）
- 用
clientWidth/clientHeight替代offsetWidth/offsetHeight（前者不含 border，但更轻） - 真需要频繁测尺寸，改用
ResizeObserver（注意：老旧 Chrome/Android WebView 可能不支持，需降级为节流后的scroll监听）
getBoundingClientRect()、一个没节流的 scroll、一段反复拼接的 innerHTML，都可能让 1.1GHz 的 CPU 拼命喘气。选工具前，先看它会不会悄悄触发 layout。 
