前段时间接手了一个老项目做性能调整，Lighthouse 跑出来 TBT将近 秒使用者反馈 “点了没反应”。

我一层一层往里查，发现问题几乎全出在 JavaScript 上：高频事件没有节流、DOM 操作在循环里反复查询、缓存策略几乎没有…，更别提模块化方案了CommonJS 和 ES Module 混用，打包出来的 chunk 一塌糊涂。

花了将近一周时间做调整。把所有踩过的坑和解法整理成这篇文章，分三个部分：执行效率、缓存策略、模块化加载。

至于第一部分。执行效率——让 JS 跑得更快

先说一个心态问题

使用者痛点：页面卡顿、交互延迟，让使用者产生“卡死”感。

调整之前我想先说一件事：JS 调整不是每次写代码都要做的事。

过度调整有两个代价：一是让代码可读性变差，二是浪费了大量时间在没有瓶颈的地方。我的原则是先用 Performance 面板找到真正的慢点，再有针对性地调整。盲目调整往往是在做无用功。怎么说呢，

真正值得花时间做 JS 调整的时机。通常是项目大改版、性能指标出了问题、或者某段代码已经让团队成员看不懂了。

从高频事件来看。节流和防抖救了我

使用者痛点：scroll/resize 触发后页面卡顿，CPU 占用飙升。

节流 ：固定时间间隔内只执行一次适合需要持续触发但不需要每次都响应的场景。

function throttle {
let timer = null;return function {
if return;timer = setTimeout => {
fn.apply;timer = null;},delay)，};}
// 窗口 resize，100ms 内最多执行一次
window.addEventListener => {
recalculateLayout;},100))，// 滚动加载，200ms 间隔
window.addEventListener => {
checkLoadMore;},200))，

防抖 ：事件停止触发后等待一段时间再执行，适合“使用者停下来再响应”的场景。

function debounce {
let timer = null;return function {
clearTimeout;timer = setTimeout => {
fn.apply;},delay)，};}
// 搜索框输入，使用者停止输入 300ms 后才发请求
searchInput.addEventListener => {
fetchSearchResults;},300))，

记住：节流是“每隔一段时间执行一次”，防抖是“停下来之后执行一次”。

至于事件委托。DOM 节点多了照样丝滑

使用者痛点：# 列表上百项，每项绑定独立监听器导致内存泄漏和响应慢。

之前项目里有个列表，几百个

每个都绑了 click 事件。几百个事件监听器挂在内存里列表动态增删的时候还要手动加/移除监听，又慢又容易出 bug。

事件委托原理：利用事件冒泡，把事件绑定到父元素上。通过

// 错误写法：给每个 li 单独绑定
document.querySelectorAll.forEach(li => {
li.addEventListener;})，话说回来，// 正确写法：委托给父元素
document.querySelector.addEventListener => {
const li = e.target.closest;if return，handleItemClick;})，

改完之后不管列表有多少项，监听器永远只有一个。动态新增的

自动享受一样的事件处理，再也不用在增删节点时手动管理监听器了。

DOM 操作缓存：循环里查 DOM 是大忌

使用者痛点：# 循环中频繁查询 DOM 导致渲染卡顿、FPS 大幅下降。

// 每次循环都查询 DOM，极慢
for {
document.querySelector.appendChild);}
// 缓存 DOM 引用，只查一次
const list = document.querySelector;// 用 DocumentFragment 批量操作，一次性插入
const fragment = document.createDocumentFragment;for {
fragment.appendChild);}
list.appendChild;老实说，

---