Цикл событий JavaScript, который управляет вашей веб-страницей, работает совсем не так, как тот, что питает сервер Node.js. Это несоответствие может привести к зависанию интерфейса или перегрузке ввода-вывода (I/O), если не проявлять осторожность. Понимание того, где они расходятся, критически важно для всех, кто пишет асинхронный код, работающий в обеих средах.

Почему это различие важно

Цикл событий не определен спецификацией ECMAScript; он реализован в хост-среде. Браузеры должны сохранять отзывчивость страницы во время отрисовки кадров, в то время как Node.js построен вокруг неблокирующего ввода-вывода. Смешивание паттернов, работающих в одной среде, с другой, может привести к трудновоспроизводимым ошибкам: длинная цепочка промисов может остановить перерисовку (repaint) в браузере, а бесконечный цикл process.nextTick может помешать Node.js достичь фаз ввода-вывода.

Пошаговый цикл браузера

В браузере цикл выполняет один цикл, который чередует выполнение задач, очистку микрозадач и рендеринг:

  1. Выполняется одна макрозадача (обработчик клика, setTimeout и т. д.).
  2. Выполняются все микрозадачи (промисы, queueMicrotask).
  3. Если пришло время кадра, происходит отрисовка (paint) и композиция для достижения целевых 60 кадров в секунду (fps).
  4. Повторение.

Два API предоставляют разработчикам явные точки входа в этот цикл:

  • requestAnimationFrame — вызывается непосредственно перед тем, как браузер выполнит отрисовку. Это лучшее место для анимаций, так как обратный вызов (callback) выполняется после текущих микрозадач, но до следующего кадра.
  • requestIdleCallback — вызывается, когда у браузера нет высокоприоритетных задач. Это полезно для задач с низким приоритетом, таких как аналитика или предварительная загрузка данных.

Ловушка: голодание микрозадач

Поскольку браузер очищает очередь микрозадач перед отрисовкой, длинная цепочка промисов может привести к тому, что интерфейс никогда не будет перерисован. Стек вызовов (call stack) не блокируется; страница просто никогда не доходит до этапа рендеринга, что пользователь воспринимает как зависание.

Цикл Node.js на базе libuv

Node.js делегирует управление циклом библиотеке libuv — библиотеке на языке C, которая разделяет работу на отдельные фазы, каждая из которых имеет свою очередь:

  1. Timers — обратные вызовы от setTimeout и setInterval.
  2. Pending callbacks — отложенные обратные вызовы ввода-вывода, которые уже завершились на уровне ОС.
  3. Poll — получение новых событий ввода-вывода (чтение файлов, сетевые данные).
  4. Check — выполнение обратных вызовов setImmediate.
  5. Close callbacks — срабатывают при закрытии сокета или дескриптора.

Два конструкта находятся вне этого порядка фаз:

  • process.nextTick — выполняется перед очередью микрозадач, сразу после завершения текущей операции.

Ловушка: голодание ввода-вывода

Если функция многократно планирует process.nextTick, не уступая управление циклу, Node.js никогда не перейдет дальше шага «next-tick». Сетевые запросы, чтение файлов и таймеры будут простаивать, что вызовет скачки задержки на стороне сервера или полное зависание.

setImmediate против setTimeout на практике

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

  • В коде верхнего уровня — порядок не гарантирован; он зависит от того, насколько быстро запускается процесс.
  • Внутри обратного вызова ввода-вывода — порядок детерминирован: setImmediate выполняется перед setTimeout(fn, 0). После завершения фазы Poll, libuv переходит к фазе Check (где работает setImmediate), прежде чем снова войти в фазу Timers для выполнения таймера с нулевой задержкой.

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

Ключевые различия одним взглядом

  • Цель: Браузеры отдают приоритет визуальным обновлениям; Node.js — готовности ввода-вывода.
  • Хук для рендеринга: requestAnimationFrame (только браузер).
  • Хук конкретной фазы: setImmediate (только Node, срабатывает в фазе Check).
  • Высокоприоритетная очередь: process.nextTick (только Node, выполняется перед микрозадачами).
  • Риск голодания: Длинные цепочки промисов в браузерах; бесконтрольные process.nextTick в Node.js.

На что обратить внимание в дальнейшем

Если вы поддерживаете кодовую базу, которая работает в обеих средах (например, изоморфные библиотеки), проверьте все места, где вы:

  • Выстраиваете длинные цепочки промисов, не уступая управление циклу событий. Вставляйте await new Promise(r => setTimeout(r, 0)) или используйте requestIdleCallback в браузере, чтобы дать рендереру шанс на отрисовку.
  • Используете process.nextTick для задач, которые можно отложить. Предпочитайте setImmediate или обычный промис, если вам не требуется мгновенная срочность «next-tick».
  • Считаете, что setTimeout(fn, 0) и setImmediate взаимозаменяемы. Тестируйте порядок выполнения внутри обратных вызовов ввода-вывода, если последовательность имеет значение.

Основные выводы

Event loop — это планировщик, специфичный для конкретной среды выполнения, а не универсальная особенность JavaScript. Браузеры встраивают рендеринг в цикл; Node изолирует операции ввода-вывода (I/O) в фазы libuv. Неправильное использование механизмов приоритетности — микрозадач (microtasks) в браузере или process.nextTick в Node — может привести к «голоданию» (starvation) тех частей системы, для обслуживания которых предназначена каждая среда. Приводите свои асинхронные паттерны в соответствие с моделью цикла хоста, и вы сможете избежать как зависания страниц, так и блокировки серверов.