Javascript Function.apply与Function.prototype.apply

我最近通过调用

console.log.toString（）

查看了Firebug

console.log

的代码，得到了以下结果：

function () { return Function.apply.call(x.log, x, arguments); }

只要我理解，这会导致调用

函数。apply

将其

this

引用

x.log

，参数为

x

和

参数

。由于

Function.apply

本身调用函数，这将导致调用

x.log

，其

this

引用

x

和

参数作为其参数

这就引出了我的问题：是否有任何理由调用
函数。以这种方式应用
，而不仅仅是使用
函数。原型。应用
？或者换句话说，上面的和返回x.log.apply（x，参数）

之间有什么区别吗

编辑：由于它是开源的，我快速查看了firebug源代码，找到了创建它的地方（，第73行）：

我现在几乎可以肯定，这与

函数处于不同的范围有关，这是我在对pst回答的第一次评论中所说的，但我仍然不完全理解。我可能会对此做进一步的研究。
考虑一下：

Function.hasOwnProperty("apply")             // false
Function.apply == Function.prototype.apply   // true
Function.__proto__ == Function.prototype     // true in FF which exposes proto

所以Function.apply可以工作，因为函数的[[prototype]]是。在这种情况下，两者都应按预期工作

然而，考虑正常规则仍然适用：
var f = function () {};
f.apply = "nubbits";
f.apply(/* err */);

当然，我认为更改代码< >应用< /code >（尤其是不兼容的方式）是“可疑代码”，但这两种形式可能是不同的。就个人而言，我不适应这种假设的情况，我在我的代码中使用了
f.apply
。
我想知道这一点——那么为什么使用
函数.prototype.apply
比
myFunc.apply
（OP的另一个问题）更好呢？@Ian可能更喜欢“显式形式”。我想不出我在代码中遇到的一个明显的原因——我，我更喜欢
fn.apply
。（如果有人改变了它的功能，那么这就取决于他们了。）因此，这样做只是为了阻止改变
console.log.apply
？很难想象这是唯一的原因。。。我还认为这是可以做到的，因为
函数
（调用
应用
的函数）处于另一个范围，这很可能是这里的问题：@YingYang好吧，如果他们真的愿意，可以更改
函数。原型。应用
。与后者不同的是，有人可能在不显式更改原型的情况下创建“真正特殊的函数对象”。。就我个人而言，我不会编写适应这种情况的代码；如果代码没有使自定义应用程序兼容，那么其他人就破坏了它——不是我。必须做出一些假设，我会坚持这个假设。后一个例子只是为了说明正常的自身属性阴影原型规则仍然适用。我更喜欢/使用
fn.apply
。我同意你的看法，我也不会那样做。这就是为什么我很难相信这是唯一的原因。另外，如果您不想阻止某人更改
apply
的功能，您是否也应该考虑阻止某人更改
call
的功能<代码>函数.apply.call在这种情况下没有多大用处。我编辑了我的问题，以包含Firebug原始源代码和注释，我几乎可以肯定这与不同的作用域有关。你的答案仍然很好，这就是为什么我对它投了更高的票。我很好奇为什么代码不只是在标准闭包方法中使用
Cu.evalInSandbox（“Function”，sandbox）
（函数对象显然是返回的），但显然这是有原因的。。实际上，这也没什么意义，因为
函数不应该关闭；除非
evalInSandbox
中有更多的魔力。。
var f = function () {};
f.apply = "nubbits";
f.apply(/* err */);