Почему отладчик Chrome считает закрытую локальную переменную неопределенной?

С этим кодом:

function baz() {
  var x = "foo";

  function bar() {
    debugger;
  };
  bar();
}
baz();

Я получаю этот неожиданный результат:

Когда я меняю код:

function baz() {
  var x = "foo";

  function bar() {
    x;
    debugger;
  };
  bar();
}

Я получаю ожидаемый результат:

Кроме того, если есть какой-либо вызов evalвнутри внутренней функции, я могу получить доступ к своей переменной, как я хочу (не важно, что я передаю eval).

Между тем, инструменты разработки Firefox дают ожидаемое поведение в обоих случаях.

Что случилось с Chrome, что отладчик ведет себя менее удобно, чем Firefox? Я наблюдал такое поведение в течение некоторого времени, вплоть до бета-версии 41.0.2272.43 (64-разрядная версия).

Это то, что движок Chrome javascript «выравнивает» функции, когда это возможно?

Интересно , если я добавляю вторую переменную , которая будет ссылаться во внутренней функции, тоx переменная еще не определена.

Я понимаю, что при использовании интерактивного отладчика часто встречаются причуды с определением области действия и переменных, но мне кажется, что на основе спецификации языка должно быть «лучшее» решение этих причуд. Поэтому мне очень любопытно, связано ли это с оптимизацией Chrome дальше, чем с Firefox. А также, могут ли эти оптимизации быть легко отключены во время разработки (возможно, их следует отключить, когда инструменты разработки открыты?).

Кроме того, я могу воспроизвести это с точками останова, а также с debuggerзаявлением.

Я нашел отчет о проблеме v8, который точно о том, что вы спрашиваете.

Теперь, чтобы подвести итог сказанному в отчете о проблеме ... v8 может хранить переменные, которые являются локальными для функции в стеке или в объекте "context", который живет в куче. Он будет размещать локальные переменные в стеке, пока функция не содержит внутренней функции, которая на них ссылается. Это оптимизация . Если какая-либо внутренняя функция ссылается на локальную переменную, эта переменная будет помещена в объект контекста (т.е. в кучу, а не в стек). Случай evalособенный: если он вызывается внутренней функцией, все локальные переменные помещаются в объект контекста.

Причина для объекта контекста в том, что в общем случае вы можете вернуть внутреннюю функцию из внешней, и тогда стек, который существовал во время выполнения внешней функции, больше не будет доступен. Поэтому все, к чему обращается внутренняя функция, должно пережить внешнюю функцию и жить в куче, а не в стеке.

Отладчик не может проверить те переменные, которые находятся в стеке. Что касается проблемы, возникающей при отладке, один из участников проекта говорит :

Единственное решение, о котором я могу подумать, это то, что всякий раз, когда включен devtools, мы бы удаляли весь код и перекомпилировали с принудительным распределением контекста. Это резко ухудшило бы производительность при включенном devtools.

Вот пример «если какая-либо внутренняя функция ссылается на переменную, поместите ее в объект контекста». Если вы запустите это, вы сможете получить доступ xк debuggerоператору, даже если xон используется только в fooфункции, которая никогда не вызывается !

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

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

  function bar() {
    debugger;
  };

  bar();
}
baz();

Как сказал @Louis, это вызвано оптимизацией v8. Вы можете пройти стек вызовов к кадру, где видна эта переменная:

Или заменить debuggerна

eval('debugger');

eval откажется от текущего чанка

Я также заметил это в nodejs. Я полагаю (и я признаю, что это только предположение), что когда код компилируется, если xне появляется внутри bar, он не становится xдоступным внутри области действия bar. Это, вероятно, делает его немного более эффективным; проблема в том , кто забыл (или не волнует) , что даже если там нет xв bar, вы не могли бы решить , чтобы запустить отладчик и , следовательно , по- прежнему необходимо получить доступ xиз внутренней bar.

Вау, действительно интересно!

Как уже упоминали другие, это, похоже, связано scope, но более конкретно, связано с debugger scope. Когда внедренный скрипт оценивается в инструментах разработчика, он, кажется, определяетScopeChain , что приводит к некоторой причуде (так как он связан с областью инспектора / отладчика). Вариант того, что вы опубликовали, таков:

(РЕДАКТИРОВАТЬ - на самом деле, вы упоминаете об этом в своем первоначальном вопросе, да , мой плохой! )

function foo() {
  var x = "bat";
  var y = "man";

  function bar() {
    console.log(x); // logs "bat"

    debugger; // Attempting to access "y" throws the following
              // Uncaught ReferenceError: y is not defined
              // However, x is available in the scopeChain. Weird!
  }
  bar();
}
foo();

Для амбициозных и / или любопытных, охват (хех) источника, чтобы увидеть, что происходит:

https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/inspector https://github.com/WebKit/webkit/tree/master/Source/JavaScriptCore/debugger

Я подозреваю, что это связано с перемещением переменных и функций. JavaScript переносит все объявления переменных и функций в начало функции, в которой они определены. Подробнее здесь: http://jamesallardice.com/explaining-function-and-variable-hoisting-in-javascript/

Могу поспорить, что Chrome вызывает точку останова с переменной, недоступной для области, потому что в функции больше ничего нет. Это похоже на работу:

function baz() {
  var x = "foo";

  function bar() {
    console.log(x); 
    debugger;
  };
  bar();
}

Как это сделать:

function baz() {
  var x = "foo";

  function bar() {
    debugger;
    console.log(x);     
  };
  bar();
}

Надеюсь, что и / или ссылка выше помогает. Это мой любимый вид ТАК вопросов, кстати :)