> Что происходит при проверке статуса Promise в JavaScript, если он может выполниться раньше? (JavaScript)

Короткий ответ

Проверка статуса Promise в JavaScript не имеет гонки с его выполнением: Promise всегда асинхронен, даже если resolve/reject вызываются синхронно. Методы .then(), .catch() и .finally() регистрируют callback'и в microtask queue, которые выполняются после завершения текущего синхронного кода. Статус Promise (pending/fulfilled/rejected) проверяется только через эти методы или await - прямой синхронной проверки не существует.

Подробное объяснение

Promise в JavaScript спроектирован так, чтобы гарантировать асинхронное выполнение callback'ов, независимо от того, когда вызывается resolve() или reject(). Это называется "guaranteed asynchrony" - даже если Promise уже выполнен, .then() всё равно помещает callback в microtask queue, а не вызывает его синхронно.

Механизм работы:

• При создании Promise его статус - pending
• Вызов resolve(value) меняет статус на fulfilled и сохраняет значение
• Вызов reject(reason) меняет статус на rejected и сохраняет причину
• Методы .then(), .catch(), .finally() проверяют статус Promise:
  • Если статус pending - callback добавляется в очередь обработчиков (handlers queue)
  • Если статус уже fulfilled или rejected - callback помещается в microtask queue для немедленного выполнения после текущего синхронного кода

Это означает, что даже если Promise выполнился до вызова .then(), callback не выполнится синхронно - он будет отложен до завершения текущего стека вызовов. Event loop гарантирует, что microtask'и (включая .then callback'и) выполняются только после того, как стек вызовов опустеет.

На практике

На практике это важно для:

• Предсказуемого порядка выполнения кода - можно быть уверенным, что все синхронные операции завершатся до выполнения асинхронных callback'ов
• Избежания race conditions - Promise не может "убежать" вперёд и выполнить callback раньше, чем ожидается
• Правильной работы с async/await - await также гарантирует асинхронность, даже если Promise уже resolved

Типичный сценарий: инициализация приложения, где Promise может быть resolved до того, как подпишется обработчик. Благодаря guaranteed asynchrony, обработчик всё равно получит значение, но после текущего синхронного кода.

Пример кода

JAVASCRIPT
const promise = new Promise(resolve => {
  console.log('1: внутри Promise');
  resolve('значение');
});

console.log('2: после создания Promise');

promise.then(value => {
  console.log('3: в .then, значение:', value);
});

console.log('4: после .then');

// Вывод:
// 1: внутри Promise
// 2: после создания Promise
// 4: после .then
// 3: в .then, значение: значение

Даже хотя resolve() вызван синхронно, .then() callback выполняется только после завершения всего синхронного кода (строки 2 и 4).

Как отвечать на собеседовании

Начни с ключевого понятия - guaranteed asynchrony. Объясни, что Promise всегда асинхронен, независимо от момента вызова resolve/reject. Упомяни microtask queue и event loop. Приведи пример с порядком вывода, чтобы показать разницу между синхронным и асинхронным выполнением. Подчеркни, что прямой синхронной проверки статуса Promise не существует - только через .then(), .catch(), .finally() или await.

Что проверяет интервьюер

• Понимание асинхронной природы Promise и guaranteed asynchrony
• Знание event loop и microtask queue
• Умение предсказывать порядок выполнения кода с Promise
• Понимание разницы между синхронным и асинхронным выполнением
• Способность объяснить, почему Promise не может выполниться "раньше" проверки

Типичные ошибки

• Утверждение, что если Promise уже resolved, то .then() выполнится синхронно
• Путаница между microtask queue и macrotask queue (setTimeout и Promise)
• Предположение, что можно синхронно прочитать статус Promise (например, promise.status)
• Непонимание, что await также гарантирует асинхронность, даже для уже resolved Promise
• Ошибка в порядке выполнения: думать, что .then() callback выполнится до следующей строки синхронного кода