Что сработает первое, setInterval или Promise

Короткий ответ: в типичном примере первым сработает Promise.then, а не setInterval. Причина не в том, что Promise быстрее. Причина в том, что браузер по-разному планирует эти callback.

Promise.then добавляет микрозадачу. setInterval регистрирует таймер, callback которого будет выполняться как задача таймера. Когда текущий синхронный код закончился, браузер делает microtask checkpoint. Он выполняет микрозадачи до опустошения очереди. Только после этого он может перейти к следующей задаче, например к timer callback.

Простой пример для ответа:

setInterval(() => {
  console.log("interval");
}, 0);

Promise.resolve().then(() => {
  console.log("promise");
});

console.log("sync");

Ожидаемый порядок первых логов в браузере будет таким: sync, потом promise, потом interval. Синхронный код идет первым, потому что микрозадачи не прерывают текущий call stack. После него выполняется микрозадача Promise. И только затем браузер добирается до задачи таймера.

Хорошая формулировка может звучать так:

Если речь про браузер и оба callback запланированы из одного синхронного участка кода, раньше выполнится Promise.then. Он попадает в очередь микрозадач. Callback setInterval будет задачей таймера. После текущего стека браузер сначала выполнит все микрозадачи и только потом перейдет к таймерам.

Такая фраза лучше, чем просто "Promise всегда первый". Она показывает границы ответа: браузер, один синхронный участок кода, текущий стек и ближайшая задача таймера.

Пример, где правило "Promise первый" нужно уточнить:

setInterval(() => {
  console.log("interval start");

  Promise.resolve().then(() => {
    console.log("promise inside interval");
  });

  console.log("interval end");
}, 1000);

Внутри уже запущенного callback порядок будет таким: interval start, interval end, promise inside interval. Promise не прерывает текущий callback. Но микрозадача выполнится до того, как браузер возьмет следующую задачу.

Для собеседования важно связать ответ с интерфейсом. setInterval не гарантирует точное время выполнения. Его callback может задержаться, если главный поток занят синхронной работой, длинной очередью микрозадач, обработкой событий или если вкладка работает в фоне.

Если вы делаете счетчик, polling или обновление UI, не стройте логику так, будто interval сработает идеально каждые N миллисекунд. Проверяйте реальное время, очищайте таймеры и учитывайте, что async-операции могут завершаться не в том порядке, в котором стартовали.

Плохой пример для компонента: интервал запускается, но никогда не очищается. Еще хуже, если каждый тик отправляет запрос и не ждет завершения предыдущего.

// Плохо: interval продолжит жить после размонтирования компонента
useEffect(() => {
  setInterval(() => {
    refreshData();
  }, 5000);
}, []);

Так можно получить лишние запросы, обновление старого состояния и утечку. Если запросы идут дольше интервала, ответы могут прийти не по порядку. Старый ответ перезапишет новые данные, и UI покажет неактуальное состояние.

Безопаснее сохранить id, очистить таймер, не запускать второй запрос поверх первого и отменить активный запрос при cleanup:

useEffect(() => {
  let ignore = false;
  let inFlight = false;
  let controller;

  const load = async () => {
    if (inFlight) return;

    inFlight = true;
    controller = new AbortController();

    try {
      const data = await fetchItems({ signal: controller.signal });

      if (!ignore) {
        setItems(data);
      }
    } finally {
      inFlight = false;
    }
  };

  load();
  const id = setInterval(load, 5000);

  return () => {
    ignore = true;
    controller?.abort();
    clearInterval(id);
  };
}, [fetchItems]);

Если ваша функция запроса не принимает AbortSignal, используйте флаг актуальности или номер запроса и игнорируйте устаревший результат. Главное не давать старому async-результату менять состояние после ухода со страницы или после более свежего ответа.

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

function loop() {
  Promise.resolve().then(loop);
}

// Плохо: такая цепочка может не дать браузеру перейти к таймерам и рендеру
loop();

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