location.href属性与location.assign（）方法

使用location.href = url和之间在JavaScript内存消耗方面是否有任何特别的优点/缺点location.assign(url)？

我想我想知道是否需要更多的内存来访问方法而不是设置属性。

我一直使用，从来没有遇到过以下问题：

location.href = url;

调用一个函数应该比访问该属性慢一点，但是就内存而言，我的拙见并不应该有太大的不同。

我个人更喜欢调用函数，因为调用函数给我一个更好的印象，即某事物正在运行，而不仅仅是变化的变量的值。

但是可能是的，虽然它可能取决于JavaScript引擎的实现，但确实location.href = url;比更快location.assign(url)，请参阅我刚刚创建的测试。

我知道这很旧，但是当我寻找一种方法来检查单元测试是否重定向到正确的URL时，我偶然发现了这一点。

window.location.assign()如果您更关心测试，我会去的。使用函数可以模拟该函数并检查url输入参数。

因此，使用笑话：

window.location.assign = jest.fn();

myUrlUpdateFunction();

expect(window.location.assign).toBeCalledWith('http://my.url');

// Clean up :)
window.location.assign.mockRestore();

在使用location.href = url而不是location.assign（url）之间的JavaScript内存消耗方面是否有任何特别的优点/缺点？

没有

恰好有零差异。

这样做的原因是简单的。每次浏览器加载新页面时，它都会使用该VM中运行的该页面的脚本来启动一个新的Javascript'VM'。运行问题中的任何一条语句时，都在指示浏览器加载新页面，这意味着销毁当前VM（并释放与其关联的所有内存）并为新页面加载全新的VM。

除任何奇怪的浏览器错误外，净效果始终相同。您的脚本正在具有完全相同的内存消耗的全新VM中运行。

分配

如果您正在浏览器中使用location对象，并且希望能够在Node JS上运行此代码（例如，用于测试或等距代码），则可以使用ulocationLocation对象的通用/等距实现。完全披露：我是该软件包的作者。

在Windows Server 2008 R2 / 7 64位上测试了我的机器/浏览器http://jsperf.com/location-href-vs-location-assign/2的Chrome 40.0.2214.93 32位

location.assign比location.href慢15％。