首頁猿問為什么Chrome調(diào)試器認(rèn)為封閉局...

為什么Chrome調(diào)試器認(rèn)為封閉局部變量是未定義的？

JavaScript

慕虎7371278 2019-06-19 19:22:24

為什么Chrome調(diào)試器認(rèn)為封閉局部變量是未定義的？使用此代碼：function baz() { var x = "foo"; function bar() { debugger; }; bar();}baz();我得到了一個意想不到的結(jié)果：當(dāng)我更改代碼時：function baz() { var x = "foo"; function bar() { x; debugger; }; bar();}我得到了預(yù)期的結(jié)果：另外，如果有人打電話到eval在內(nèi)部函數(shù)中，我可以像我想做的那樣訪問我的變量(不管我傳遞給什么)eval).同時，F(xiàn)irefoxdev工具在這兩種情況下都提供了預(yù)期的行為。Chrome的什么地方，調(diào)試器的行為不如Firefox那么方便？我觀察這種行為已經(jīng)有一段時間了，包括41.0.2272.43測試版(64位)。是Chrome的javascript引擎在可能的情況下“平復(fù)”了這些功能嗎？有趣的是，如果我添加第二個變量，是在內(nèi)部函數(shù)中引用，x變量仍未定義。我理解在使用交互式調(diào)試器時經(jīng)常會出現(xiàn)范圍和變量定義的怪癖，但在我看來，基于語言規(guī)范，應(yīng)該有一個解決這些怪癖的“最佳”解決方案。所以我很好奇這是否是因為Chrome比Firefox更加優(yōu)化。此外，這些優(yōu)化在開發(fā)過程中是否可以很容易地被禁用(也許在開發(fā)工具打開時應(yīng)該禁用這些優(yōu)化？)。此外，我還可以使用斷點以及debugger聲明。

查看完整描述

3 回答

慕雪6442864

TA貢獻(xiàn)1812條經(jīng)驗獲得超5個贊

我找到了一個V8發(fā)行報告這正是你想要的。

現(xiàn)在，總結(jié)一下那份報告中所說的話.V8可以存儲堆棧中函數(shù)的本地變量。或在堆上的“上下文”對象中。它將在堆棧上分配局部變量，只要函數(shù)不包含引用它們的任何內(nèi)部函數(shù)。這是一個優(yōu)化..如果任何內(nèi)部函數(shù)是指局部變量，這個變量將放在上下文對象中(即堆上而不是堆棧上)。案例eval是特殊的：如果它是由一個內(nèi)部函數(shù)調(diào)用的，全局部變量放在上下文對象中。

上下文對象的原因是，通常您可以從外部函數(shù)返回內(nèi)部函數(shù)，然后外部函數(shù)運行時存在的堆棧將不再可用。因此，內(nèi)部函數(shù)訪問的任何東西都必須生存于外部函數(shù)中，并且生活在堆上而不是堆棧上。

調(diào)試器無法檢查堆棧上的那些變量。關(guān)于調(diào)試中遇到的問題，有一個項目成員說:

我能想到的唯一解決方案是，每當(dāng)DevTools打開時，我們就會取消所有代碼，并使用強制上下文分配重新編譯。不過，在啟用DevTools的情況下，這將顯著地降低性能。

下面是“如果任何內(nèi)部函數(shù)引用變量，將其放入上下文對象”的示例。如果你運行這個，你就可以訪問x在debugger聲明，盡管x僅在foo職能，從未被稱為!

function baz() {
  var x = "x value";
  var z = "z value";

  function foo () {
    console.log(x);
  }

  function bar() {
    debugger;
  };

  bar();}baz();

反對回復(fù) 2019-06-19

神不在的星期二

TA貢獻(xiàn)1963條經(jīng)驗獲得超6個贊

我在NodeJS中也注意到了這一點。我相信(我承認(rèn)這只是猜測)，當(dāng)代碼被編譯時，如果x不出現(xiàn)在里面bar，它不會x的范圍內(nèi)可用。bar..這可能會使它稍微更有效率；問題是有人忘記了(或者根本不在乎)，即使沒有x在……里面bar，您可能決定運行調(diào)試器，因此仍然需要訪問x從里面bar.