JavaScript函数调用开销小，性能关键在于调用方式是否利于引擎优化；应保持调用模式稳定、避免参数泄漏、复用函数对象、慎用隐式高开销操作。
JavaScript 函数调用本身的开销其实非常小，真正影响性能的，是调用方式是否利于引擎优化。V8、QuickJS 等现代引擎不会因为“多调了一次函数”就明显变慢，而是对不可预测、结构混乱或副作用频繁的调用路径“失去信心”，从而跳过关键优化——比如内联缓存（IC）、隐藏类匹配、JIT 升级甚至尾调用复用。
让每次调用都可预测
引擎依赖稳定的调用模式建立优化假设。一旦参数数量、类型或结构频繁变化，IC 就容易失效，函数可能长期停留在解释执行层。
- 固定形参优于 rest 参数：
function draw(x, y, color)比function draw(...args)更易被 JIT 识别和优化 - 避免在热路径中用
arguments或转成数组（如[...arguments]），这会触发“参数泄漏”，强制降级编译 - 高频调用点（如渲染循环、滚动监听）传参尽量用对象字面量：
update({ x: 10, y: 20, animated: true })，语义清晰且结构稳定
复用函数对象，别在循环里造函数
每次声明箭头函数或函数表达式，都会创建新函数对象——不仅增加 GC 压力，还会让 V8 无法复用内联缓存，也无法对同一逻辑做统一优化。
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- ❌
list.forEach(item => process(item))→ 每次 forEach 都新建闭包 - ✅ 提前定义：
const process = item => { ... };再传入list.forEach(process) - 事件监听同理：用具名函数绑定 scroll/input，而不是
el.addEventListener('scroll', () => {...})
递归不是问题，失控的调用栈才是
V8 不支持通用尾调用优化（TCO），但对严格尾递归仍保留部分优化机会。更稳妥的做法是主动迭代化。
立即学习“Java免费学习笔记（深入）”；
- 非尾递归（如
return n * factorial(n-1)）会逐层累积栈帧，深度稍大即报错 - 尾递归需满足：最后一步是纯调用 + 无后续计算 + 启用
"use strict"，例如return factorial(n-1, acc * n) - 优先改写为 while 循环或显式栈（
const stack = [...]），既可控又免栈溢出
警惕隐式开销：那些看起来像调用、实则很重的操作
有些“函数调用”背后藏着同步布局、跨上下文访问或动态求值，它们的代价远超普通 JS 调用。
- 避免在动画帧或高频回调中读取
offsetWidth、getBoundingClientRect()—— 强制回流 - 不要把
Date.now、Math.random当默认参数：function log(msg, ts = Date.now())→ 每次调用都执行 - 慎用高阶包装（如
throttle(fn)返回新函数），若 fn 本身是热路径，包装会切断 JIT 优化链
