Внутри Promise

Promise — это три поля и список

Снимите API, и объект Promise в V8 окажется маленьким. Его существенные внутренние слоты:

• [[PromiseState]] — одно из pending, fulfilled, rejected. Начинается с pending и переходит ровно один раз. Этот инвариант урегулирования единожды — сердце автомата: после ухода из pending никакой более поздний resolve/reject его не изменит.
• [[PromiseResult]] — значение, которым он fulfilled, или причина, которой rejected. Бессмысленно, пока pending.
• [[PromiseFulfillReactions]] / [[PromiseRejectReactions]] — два списка записей PromiseReaction, обработчиков, зарегистрированных через .then/.catch, пока Promise был ещё pending. После урегулирования эти списки очищаются и заменяются результатом.

Запись PromiseReaction связывает три вещи: тип (fulfill или reject), обработчик (ваш колбэк onFulfilled / onRejected или undefined) и capability нового Promise, который вернул .then (функции resolve/reject, которые урегулируют этот нижестоящий Promise). Эта последняя часть — причина, по которой сцепление вообще работает.

Что на самом деле делает .then

promise.then(onF, onR) делает три конкретные вещи по порядку:

1. Создаёт новый Promise («result capability») и запоминает его функции resolve/reject.
2. Строит две записи PromiseReaction — одну fulfill, одну reject — каждая оборачивает совпадающий обработчик и эту новую capability.
3. Либо регистрирует, либо планирует их. Если исходный Promise ещё pending, реакции добавляются в его списки реакций и пока ничего не запускается. Если Promise уже урегулирован, .then не запускает обработчик синхронно — он немедленно ставит PromiseReactionJob как микрозадачу для совпадающей реакции.

const p = Promise.resolve(42);   // уже fulfilled значением 42
const q = p.then(v => v + 1);     // q — НОВЫЙ Promise; одна PromiseReactionJob поставлена сейчас
// q урегулируется значением 43 после того, как этот job выполнится (одной микрозадачей позже)

Итак, .then никогда не запускает ваш обработчик «прямо сейчас», даже на уже урегулированном Promise. Он всегда откладывает на микрозадачу. Эта единственная гарантия и делает порядок Promise предсказуемым: колбэк .then всегда отстоит на одну микрозадачу от урегулирования, никогда не синхронен.

Урегулирование ставит по одному job на реакцию

Когда продюсер вызывает функцию resolve (урегулируя Promise в fulfilled), движок выполняет FulfillPromise: устанавливает [[PromiseState]] в fulfilled, сохраняет значение, а затем обходит [[PromiseFulfillReactions]], ставя микрозадачу PromiseReactionJob для каждой зарегистрированной реакции. Каждый job, когда его выполнит чекпоинт микрозадач, вызывает обработчик реакции с результатом и использует возвращённое значение, чтобы урегулировать нижестоящий Promise этой реакции (у которого могут быть собственные реакции, каскадом порождающие новые jobs). Отклонение симметрично через RejectPromise и [[PromiseRejectReactions]].

Вот почему fan-out стоит N микрозадач: p.then(a); p.then(b); p.then(c) на урегулированном p регистрирует три реакции и ставит три PromiseReactionJob — a, b, c выполняются как три отдельные микрозадачи в порядке регистрации.

Лишний тик: урегулирование через thenable

Вот тонкость, спотыкающая подсчёт тиков. Если вы урегулируете Promise другим Promise (или любым thenable), движок не может принять его значение синхронно — thenable может урегулироваться позже. Поэтому ResolvePromise планирует PromiseResolveThenableJob: микрозадачу, единственная цель которой — вызвать .then внутреннего thenable, чтобы подписаться на него. Эта подписка сама по себе ещё одно откладывание. Следствие: урегулирование Promise A через Promise B добавляет лишний тик микрозадачи по сравнению с урегулированием A обычным значением, потому что движок должен отскочить через PromiseResolveThenableJob, прежде чем A сможет хотя бы начать принимать будущее состояние B.

// Обычное значение: q урегулируется одним тиком после запуска реакции p.
Promise.resolve(1).then(v => v);

// Thenable: возврат Promise из обработчика стоит лишнего тика,
// потому что внешний Promise должен принять внутренний через resolve job.
Promise.resolve(1).then(v => Promise.resolve(v));   // лишний PromiseResolveThenableJob

Это и есть механическая причина, по которой исходный await стоил три тика (разбирается в следующем уроке): спецификация оборачивала ожидаемое значение в одноразовый Promise и принимала его через thenable job. V8 7.2 (2018) сделал особый случай для нативных Promise, пропускающий эти лишние jobs.

Отслеживание необработанных отклонений

Движок также следит за отклонениями без reject-обработчика. Когда выполняется RejectPromise, а список reject-реакций пуст (не прикреплён .catch/.then(_, onR)), Promise помечается как имеющий потенциально необработанное отклонение. Хост уведомляется через HostPromiseRejectionTracker, что и порождает браузерное событие unhandledrejection и process.on('unhandledRejection') в Node. Важно, что это отложено: обработчик, прикреплённый позже в том же обороте, снимает флаг (порождает rejectionhandled), потому что прикрепление .catch регистрирует reject-реакцию, которая потребляет сохранённое отклонение. Это откладывание — причина, по которой «добавьте .catch на следующей строке» всё ещё подавляет предупреждение — а вот .catch, прикреплённый макрозадачей позже, уже нет.