JavaScript性能优化关键在精准选用代码分割、懒加载、防抖节流：代码分割用import()动态导入生成独立chunk；懒加载图片用loading="lazy"或IntersectionObserver；防抖节流需按场景自实现。
JavaScript 性能优化不是靠堆代码，而是靠在关键节点做对选择：代码分割解决首屏加载阻塞，懒加载推迟非视区资源消耗，防抖节流抑制高频回调的失控执行。三者作用域不同，混用反而容易出问题。
代码分割要用 import() 动态导入，别碰 require.ensure 或 Webpack 旧 API
现代打包器（Webpack/Vite/Rollup）只认 import() 作为代码分割入口。它返回 Promise，天然支持异步逻辑，且能被静态分析生成独立 chunk。
-
import()必须传字符串字面量或带有限制的模板字符串（如import(`./pages/${page}.js`)中page是确定值），动态拼接路径（import(path + '.js')）会导致打包失败 - 不要在循环或条件分支里无约束调用
import()，否则可能产生大量零散 chunk，增加 HTTP 请求开销 - 配合
React.lazy时，组件必须用默认导出，否则会抛Element type is invalid
const ChartComponent = React.lazy(() => import('./charts/LineChart'));
// ✅ 正确：字符串字面量，可被分割
// ❌ 错误：import('./charts/' + type + '.js') —— 打包器无法静态分析
懒加载图片和组件得区分场景：原生 loading="lazy" 仅适用于
loading="lazy" 是浏览器原生能力，不触发 JS 执行，也不支持自定义阈值或监听进入视口后的回调。它只对初始 HTML 中存在的 生效，对 JS 动态创建的图片无效。
- 需要监听滚动、计算距离、触发动画或加载后回调？必须用
IntersectionObserver - 服务端渲染（SSR）中，
loading="lazy"在首次 HTML 输出时即生效，但IntersectionObserver需等 JS 加载执行后才工作 - Vite 或 Next.js 的
Image组件默认启用懒加载，但底层仍是封装了IntersectionObserver，不是简单加loading="lazy"
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
if (entry.isIntersecting) {
const img = entry.target;
img.src = img.dataset.src; // 触发真实加载
observer.unobserve(img);
}
});
}, { threshold: 0.1 });
document.querySelectorAll('img[data-src]').forEach(img => observer.observe(img));
防抖和节流函数不能直接套用 Lodash，得看是否需要取消、是否要立即执行、是否依赖 this 上下文
_.debounce 和 _.throttle 默认绑定 this 并维护内部计时器，但在箭头函数、事件监听器或 Class 方法中容易丢失上下文或造成内存泄漏。自己写更可控。
- 搜索框输入防抖：用
setTimeout+clearTimeout，每次输入清前一个定时器，延迟后执行请求 - 窗口 resize 节流：用时间戳比对，确保至少间隔
nms 才执行一次，避免requestAnimationFrame在后台标签页失效 - 如果防抖函数需被多次调用并支持手动取消（比如用户切换页面前清理），必须暴露
cancel方法
function debounce(fn, delay) {
let timer = null;
return function(...args) {
clearTimeout(timer);
timer = setTimeout(() => fn.apply(this, args), delay);
};
}
// 使用
const handleSearch = debounce(() => fetch(`/api/search?q=${input.value}`), 300);
真正难的不是写出这三个技术点，而是判断该用哪个：滚动加载列表用懒加载，不是节流；表单校验用防抖，不是节流；路由切换时按需加载模块用代码分割，不是懒加载图片。边界模糊的地方，往往才
