JavaScript性能优化关键在识别真实瓶颈：90%卡顿源于setTimeout嵌套、未节流的resize/scroll事件或强制同步布局；应集中读写操作、用requestAnimationFrame批量更新、避免循环中频繁DOM访问，并警惕console.table和sourceMap误发生产环境。
JavaScript 性能优化不是靠堆技巧，而是优先识别和切断实际瓶颈。90% 的页面卡顿跟 setTimeout 嵌套、未节流的 resize/scroll 事件、或意外的强制同步布局（layout thrashing）直接相关。
避免强制同步布局（Layout Thrashing）
浏览器在读取某些 DOM 属性（如 offsetHeight、getBoundingClientRect()）时，若此前有未生效的样式修改，会立即触发重排（reflow），频繁读写交替就会卡死主线程。
- 把所有“读”操作集中在一起，所有“写”操作集中在一起
- 用
requestAnimationFrame批量处理动画帧内的 DOM 更新 - 避免在循环中反复访问
element.style.height或element.offsetWidth
错误示例：
for (let i = 0; i < items.length; i++) {
el[i].style.height = '100px'; // 写
console.log(el[i].offsetTop); // 读 → 触发重排
}
节流与防抖别混用场景
throttle 适合高频持续触发且必须定期响应的场景（比如 scroll 计算吸顶状态）；debounce 适合“最后才执行”的意图判断（比如搜索框输入后发请求）。
- 用
lodash.throttle时注意leading/trailing默认值，不加配置可能首尾都丢事件 - 原生实现
debounce必须清上一个setTimeoutID，漏掉就导致多次调用 - Vue/React 中绑定
@scroll或onScroll时不包装，等于裸奔式监听
减少闭包与长生命周期引用
闭包本身不慢，但若内部函数被挂到全局事件或定时器里，又引用了大对象（比如整个 data 响应式数据），就会阻止垃圾回收，内存悄悄上涨。
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
立即学习“Java免费学习笔记（深入）”；
- 事件监听器用完及时
removeEventListener，尤其动态创建的组件 - 避免在
setInterval回调里直接引用外部大数组，可提前提取必要字段 - Chrome DevTools 的
Memory > Take heap snapshot对比两次快照，看Closure下谁占得多
用 for 代替 forEach 真能提速？
单次遍历几万条数据时，for 比 forEach 快 2–5 倍，但差异主要来自函数调用开销和作用域创建——不是语法本身慢，而是 forEach 每次都要 new 一个执行上下文。
- 纯计算逻辑（无 DOM、无 await）且数组长度 > 10k，优先
for或for...of - 需要链式调用（
filter→map→reduce）时，for反而难维护，此时用Array.from+flat预过滤更有效 - V8 引擎对
for循环做了大量优化，但对for...in仍警告：它遍历的是属性名，不是数组索引，且包含原型链
真正拖慢 JS 的，往往不是语法选择，而是没意识到某个 console.table(data) 在生产环境开着，或者 sourceMap 文件被一起部署到了 CDN 上。
