JavaScript性能优化需先定位瓶颈：用Chrome DevTools Performance面板分析火焰图，关注Script Evaluation和Layout Thrashing；for循环比forEach快因避免闭包和函数调用开销；DOM操作应读写分离并利用合成层；内存泄漏常见于全局变量、未卸载事件监听器和闭包持有大对象。
JavaScript 性能优化不是靠堆技巧，而是优先识别瓶颈再针对性处理。没有通用“加速包”，console.time() 和浏览器 DevTools 的 Performance 面板比任何教程都管用。
怎么快速定位 JS 执行慢的函数？
别猜，用真实数据说话。打开 Chrome DevTools → Performance 标签 → 点击录制（●），操作页面后停止，看 Main 线程火焰图里哪些 function 占用时间长、是否频繁调用。
- 重点关注标记为
Script Evaluation或Function Call的长条块 - 右键某帧可选
Zoom to selection查看细节，注意调用栈深度和重复调用次数 - 若发现大量
Recalculate Style或Layout，说明 JS 正在强制同步触发重排，问题不在逻辑而在 DOM 读写顺序
为什么用 for 循环比 forEach 快？
不是语法本身快，而是 forEach 带来额外开销：每次迭代都新建作用域、执行回调函数调用、无法 break 提前退出。对大数组或热路径代码，差异明显。
const arr = new Array(100000).fill(0);
// 慢：创建 10w 次函数闭包 + 调用开销
arr.forEach((v, i) => {
if (i > 50000) return; // 无效，仍会遍历全部
});
// 快：无闭包、可中断、CPU 缓存友好
for (let i = 0; i < arr.length; i++) {
if (i > 50000) break;
}
-
for更适合数值索引密集型遍历；for...of在支持Symbol.iterator的结构（如Array,Set）上可读性好，性能接近for -
map/filter等高阶函数适合逻辑清晰、数据量小、或需函数式风格的场景，别为了“看起来高级”牺牲关键路径性能
DOM 操作卡顿，是不是 JS 太慢？
绝大多数情况不是 JS 执行慢，而是反复读写 DOM 触发了 Layout Thrashing（布局抖动）。比如循环中先 el.offsetTop 再 el.style.left = '10px'，浏览器被迫同步计算样式+布局 100 次。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
- 把所有读操作集中到前面（如批量读取
getBoundingClientRect()），所有写操作集中到后面（如一次性设置style.cssText或用classList） - 用
requestAnimationFrame批量更新动画相关 DOM，避免在事件回调中直接改样式 - 对频繁更新的元素，加
transform: translateZ(0)或will-change: transform推进合成层，减少主线程重绘压力
内存泄漏常被忽略的三个点
JS 垃圾回收不等于不会泄漏。以下模式极易导致对象长期驻留：
- 全局变量意外保留引用，比如
window.cache = {}存了大量未清理的数据 - 事件监听器没卸载，尤其在单页应用组件销毁时忘了
removeEventListener，或用addEventListener传了匿名函数（无法移除） - 闭包持有大对象，比如在定时器回调里引用了整个
component实例，而定时器没清除
用 Chrome DevTools 的 Memory 面板拍快照（Heap Snapshot），筛选 Detached DOM tree 或对比多次快照中增长最多的构造函数，比凭感觉排查准得多。
