JS `Function.prototype.caller` / `arguments.callee` 的弃用与替代方案

大家好，今天咱们来聊聊JS里那些年被我们“抛弃”的，但又不得不了解的“老朋友”：Function.prototype.caller 和 arguments.callee，以及它们那些“新欢”替代方案。

别担心，这绝对不是一场考古挖掘，而是为了让你更了解JS的“前世今生”，写出更健壮、更安全的现代代码。

开场白：时代的眼泪与历史的教训

先来个“免责声明”：Function.prototype.caller 和 arguments.callee 已经在严格模式下被禁用，并且在非严格模式下也强烈不建议使用。它们就像是JS的“坏习惯”，虽然偶尔能偷个懒，但长期来看，绝对是“损人不利己”。

但就像学习历史一样，了解这些被废弃的特性，能让我们更好地理解JS的发展脉络，避免重蹈覆辙。

第一幕：Function.prototype.caller——“谁调了我？”

Function.prototype.caller 属性返回调用当前函数的函数。简单来说，就是“我的爸爸/妈妈是谁？”。如果当前函数是由顶层代码调用的，那么 caller 的值为 null。

示例代码（非严格模式）：

function first() {
  second();
}

function second() {
  console.log(second.caller); // 输出：function first() { ... }
}

first();

在这个例子中，second 函数的 caller 是 first 函数。

问题来了：为什么不建议使用 caller？

安全风险： caller 暴露了调用栈信息，这可能被恶意代码利用，进行诸如“栈溢出”之类的攻击。想象一下，如果一个不受信任的第三方库能够访问你的调用栈，那简直就是“家门大开”，任人宰割了。
性能问题： 访问 caller 可能会导致V8引擎（或其他JS引擎）无法进行某些优化，从而降低代码的执行效率。引擎需要“暂停”优化，去查找调用栈，这会消耗额外的资源。
兼容性问题： 在严格模式下，caller 已经被禁用。依赖 caller 的代码在严格模式下会报错。

第二幕：arguments.callee——“我自己是谁？”

arguments.callee 属性指向当前正在执行的函数。它允许你在函数内部引用自身，这在匿名递归函数中特别有用。

示例代码（非严格模式）：

var factorial = function(n) {
  if (n <= 1) {
    return 1;
  } else {
    return n * arguments.callee(n - 1);
  }
};

console.log(factorial(5)); // 输出：120

在这个例子中，arguments.callee 在 factorial 函数内部被用来递归调用自身。

问题来了：为什么不建议使用 arguments.callee？

严格模式禁用： 和 caller 一样，arguments.callee 也在严格模式下被禁用。
命名空间污染： arguments 对象是一个类数组对象，它包含了函数的所有参数。向 arguments 对象添加 callee 属性会污染命名空间，增加代码的复杂性。
可读性差： 使用 arguments.callee 会让代码的可读性变差。相比于直接使用函数名进行递归调用，arguments.callee 显得更加晦涩难懂。
性能问题： 访问 arguments.callee 也会影响引擎的优化，降低代码的执行效率。

第三幕：替代方案——“新欢”上位

既然 caller 和 arguments.callee 已经被“打入冷宫”，那么我们该如何优雅地解决它们曾经解决的问题呢？

caller 的替代方案：

显式传递上下文： 最好的替代方案是显式地将调用者信息作为参数传递给被调函数。

function first() {
  second(first); // 显式传递 first 函数
}

function second(callerFunction) {
  console.log(callerFunction); // 输出：function first() { ... }
}

first();

这种方式不仅安全，而且更加清晰明了。

使用 Error.stack (谨慎使用): Error.stack 属性可以获取调用栈信息，但这是一个非标准属性，不同浏览器和环境下的实现方式可能不同。而且，解析 Error.stack 的成本较高，不建议在性能敏感的场景中使用。

function first() {
  second();
}

function second() {
  try {
    throw new Error();
  } catch (e) {
    const stackLines = e.stack.split('n');
    // stackLines[2] 包含了调用 second 函数的信息
    console.log(stackLines[2]);
  }
}

first();

arguments.callee 的替代方案：

命名函数表达式： 使用命名函数表达式可以避免使用 arguments.callee 进行递归调用。

var factorial = function factorial(n) {
  if (n <= 1) {
    return 1;
  } else {
    return n * factorial(n - 1); // 使用函数名 factorial 进行递归调用
  }
};

console.log(factorial(5)); // 输出：120

这种方式不仅避免了使用 arguments.callee，而且提高了代码的可读性。

普通函数声明： 对于非匿名函数，直接使用函数名进行递归调用即可。

function factorial(n) {
  if (n <= 1) {
    return 1;
  } else {
    return n * factorial(n - 1); // 使用函数名 factorial 进行递归调用
  }
}

console.log(factorial(5)); // 输出：120

总结：拥抱现代JS

特性	问题	替代方案	优点	缺点
`caller`	安全风险，性能问题，兼容性问题（严格模式禁用）	显式传递上下文，`Error.stack` (谨慎使用)	更安全，更清晰，避免性能问题	显式传递上下文可能需要修改函数签名；`Error.stack` 非标准，性能较差
`arguments.callee`	严格模式禁用，命名空间污染，可读性差，性能问题	命名函数表达式，普通函数声明	更清晰，更安全，避免性能问题	无

与其怀念那些“老朋友”，不如拥抱现代JS的“新欢”。使用更安全、更高效、更易读的替代方案，才能写出更健壮、更可维护的代码。

结语：温故而知新

虽然 Function.prototype.caller 和 arguments.callee 已经被废弃，但了解它们的存在和背后的原因，能让我们更好地理解JS的发展历程，避免在未来的开发中犯同样的错误。记住，技术在不断发展，我们要不断学习，拥抱变化，才能成为一名优秀的程序员。

希望今天的“讲座”能让你对JS的这些“历史遗留问题”有更深入的了解。下次再遇到类似的问题，就能游刃有余地解决啦！

发表回复 取消回复

发表回复取消回复