JavaScript this, замыкания и контекст, полный разбор причин багов в async-коде (Node.js, браузер, React)

Инцидент из продакшена “данные есть, но логика их не видит”

В одном backend-сервисе на Node.js возник странный баг: часть логов перестала записываться, при этом ошибок не было. API работало стабильно, нагрузка не изменилась, мониторинг молчал.

Код выглядел безобидно:

const logger = {
  name: "api",
  logs: [],

  log(message) {
    setTimeout(function () {
      this.logs.push({
        service: this.name,
        message
      });
    }, 100);
  }
};

Проблема проявлялась только в продакшене и только под нагрузкой.

Что реально произошло

На первый взгляд кажется, что ошибка в setTimeout. Но на самом деле ломается модель исполнения JavaScript.

Функция внутри setTimeout вызывается не как метод объекта, а как обычная функция. В этот момент JavaScript создаёт новый execution context, и значение this определяется заново.

Контекст объекта logger в этот момент уже не участвует в вызове. Поэтому this становится либо undefined (в strict mode), либо глобальным объектом в старых окружениях.

Именно поэтому строка this.logs.push(...) обращается не туда, куда ожидает разработчик.

Почему замыкание здесь не помогает

Распространённая ошибка мышления заключается в том, что замыкание якобы “сохраняет всё вокруг функции”.

На практике замыкание сохраняет только lexical environment, то есть доступ к переменным внешней функции. Но this к этому не относится.

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

Поэтому даже при наличии замыкания поведение this остаётся динамическим.

Почему баг проявляется только в async-коде

Асинхронность в JavaScript разрывает цепочку вызова.

Когда функция передаётся в очередь задач (task queue или microtask queue), она теряет исходный контекст вызова.

Поэтому такие конструкции как setTimeout, Promise.then, queueMicrotask, addEventListener, middleware в Node.js - это основные источники потери this.

Именно поэтому в синхронном коде проблема почти не проявляется.

Почему классы не решают проблему

Многие разработчики ожидают, что классы в JavaScript фиксируют контекст. Но классы - это всего лишь синтаксическая надстройка над прототипами.

class Logger {
  constructor(name) {
    this.name = name;
  }

  log(message) {
    setTimeout(function () {
      console.log(this.name);
    }, 100);
  }
}

Проблема остаётся абсолютно такой же: метод теряет контекст при передаче в callback.

Причина в том, что метод - это просто функция, а не “привязанное поведение объекта”.

Где это ломается чаще всего в реальных системах

В браузере это проявляется в обработчиках событий, особенно когда метод класса передаётся напрямую в addEventListener. В React это часто происходит при передаче методов классовых компонентов в JSX без привязки.

В Node.js проблема всплывает в middleware Express, callback-ах файловой системы и любых асинхронных обработчиках.

Во всех этих случаях общая причина одна: функция вызывается не через объект, а отдельно.

Почему setTimeout особенно опасен для контекста

setTimeout не сохраняет исходный execution context. Он помещает функцию в очередь задач и вызывает её позже как самостоятельную единицу.

Именно поэтому даже простая передача метода приводит к потере this.

setTimeout(logger.log, 100);

Здесь теряется не только контекст, но и вся связь с объектом.

Как это исправляют в реальных проектах

В современных кодовых базах есть три устойчивых подхода.

Самый распространённый - стрелочные функции, потому что они не создают собственного this и наследуют его из внешнего lexical environment.

log(message) {
  setTimeout(() => {
    this.logs.push(message);
  }, 100);
}

Второй подход - явная фиксация контекста через bind, обычно в конструкторе классов.

constructor() {
  this.log = this.log.bind(this);
}

Третий вариант - явный вызов через wrapper-функцию, особенно в React и event-driven архитектуре.

Как это связано с execution context и event loop

Чтобы полностью понять проблему, важно учитывать модель event loop.

Каждый вызов функции создаёт execution context. Но когда функция уходит в очередь задач, она теряет связь с исходным стеком вызовов.

Поэтому this всегда пересчитывается при выполнении callback-а, а не сохраняется.

Это объясняет, почему проблема проявляется именно в асинхронных сценариях и почти отсутствует в синхронных.

Почему опытные разработчики тоже ошибаются

Ошибка возникает не на уровне синтаксиса, а на уровне модели мышления.

Многие воспринимают this как часть объекта, хотя на самом деле это параметр вызова функции.

Это особенно критично при работе с async-кодом, где цепочка вызовов разрывается и контекст перестаёт быть очевидным.

Edge cases, которые часто игнорируют

Есть несколько сценариев, где проблема становится ещё менее очевидной.

В Promise-цепочках:

Promise.resolve().then(function () {
  console.log(this);
});

В микротасках контекст также теряется.

В React hooks при передаче функций между компонентами аналогичная проблема возникает при неправильной мемоизации.

В Node.js при передаче методов в middleware Express теряется связь с объектом класса сервиса.

FAQ (реальные поисковые запросы)

Почему this undefined в JavaScript?


Потому что функция вызывается без объекта-контекста, и JavaScript не привязывает this автоматически.

Почему this ломается в setTimeout?


Потому что callback вызывается как обычная функция, без объекта.

Как работает this в стрелочных функциях?


Стрелочные функции не создают собственного this и используют значение из внешнего lexical environment.

Почему в React теряется this?


Потому что методы класса передаются как ссылки и теряют привязку к экземпляру.

В чем разница между bind и call?


call вызывает функцию сразу с заданным контекстом, bind возвращает новую функцию с закреплённым this.

Итог

Проблема this в JavaScript - это не баг и не особенность отдельных API. Это следствие модели исполнения функций, где контекст определяется не объектом, а способом вызова.

Замыкания работают с переменными, event loop управляет порядком выполнения, а this всегда зависит только от того, как именно вызвана функция в конкретный момент времени.

Понимание этой модели убирает большую часть “необъяснимых” багов в JavaScript-коде, особенно в асинхронных системах.