Что такое параметр next в middleware

Обычно этот вопрос про middleware в стиле Express. Middleware получает запрос, ответ и функцию next. Обработчик может сделать проверку, записать лог, добавить данные к запросу, а потом передать управление дальше.

Коротко можно ответить так:

next() говорит фреймворку, что текущий middleware закончил работу и можно выполнять следующий обработчик. next(err) передает ошибку в специальный обработчик ошибок.

Не ограничивайтесь фразой про продолжение цепочки. Добавьте, что без next() или явного ответа клиенту запрос не завершится нормально.

Порядок выполнения зависит от порядка регистрации middleware. Вам это пригодится в BFF, dev server, SSR-приложении или API-роутах. Например, проверка авторизации должна сработать до бизнес-обработчика, а общий error handler обычно ставят после обычных routes.

app.use((req, res, next) => {
  console.log(req.method, req.url);
  next();
});

app.use((req, res, next) => {
  if (!req.user) {
    return res.status(401).json({ message: 'Unauthorized' });
  }

  next();
});

app.get('/profile', (req, res) => {
  res.json({ profile: req.user.profile });
});

В первом middleware нет ответа клиенту, поэтому нужен next(). Во втором есть развилка: если пользователя нет, ответ уже отправлен и цепочку продолжать нельзя. Если пользователь есть, можно идти дальше.

У middleware всегда должен быть понятный финал. Он передает управление дальше, завершает ответ или передает ошибку. Если смешать эти варианты, появятся зависшие запросы, двойные ответы и сложные баги в тестах.

Если middleware не может корректно продолжить работу, ошибку часто передают через next(err). Тогда общий error handler залогирует проблему, выберет статус и вернет единый формат ответа.

app.use(async (req, res, next) => {
  try {
    req.user = await loadUser(req.headers.authorization);
    next();
  } catch (err) {
    next(err);
  }
});

app.use((err, req, res, next) => {
  console.error(err);
  res.status(500).json({ message: 'Internal server error' });
});

Это лучше, чем вручную собирать разные ответы с ошибками в каждом middleware. Для клиента важен стабильный формат ошибки. Тогда React-код одинаково обработает loading, error и повтор запроса. Но учитывайте конкретный фреймворк и версию. Обработка async ошибок может отличаться, поэтому не говорите, что Express всегда сам все поймает.

next не стоит использовать как канал данных. В Express аргумент next обычно означает ошибку, поэтому next(user) выглядит как переход в ошибочную ветку, а не как передача пользователя.

Для данных используйте явное место:

app.use(async (req, res, next) => {
  const user = await loadUser(req.headers.authorization);

  req.user = user;
  // или res.locals.user = user;

  next();
});

Практический вывод простой. Следующий обработчик должен понимать, откуда брать данные, а не угадывать смысл аргумента в next. Так код проще тестировать. Еще ниже риск случайно отправить запрос в error handler. Не используйте глобальную переменную для пользователя или токена. При параллельных запросах можно получить race condition и утечку данных между пользователями.

Формулировка может звучать похоже на Next.js, но это другой API. В Next.js Middleware нет callback-параметра next как в Express. Там обычно возвращают NextResponse.next(), NextResponse.redirect() или NextResponse.rewrite().

Если на интервью вопрос задан без фреймворка, безопасная фраза такая:

Если мы говорим про Express-подобный middleware, next это callback для передачи управления дальше. В Next.js Middleware механика другая: мы возвращаем NextResponse.next() или другой ответ.

Так вы покажете, что не смешиваете разные экосистемы и готовы уточнить контекст.

Сильный ответ должен звучать не как словарное определение, а как правило для кода. В каждом middleware явно выберите один вариант. Продолжить цепочку, завершить ответ или передать ошибку. Не вызывайте next() после ответа и не используйте его для обычных данных.

Для frontend-разработчика это важно в BFF, SSR, мок-серверах, API routes и dev middleware. Ошибка в цепочке может выглядеть как "фронт завис", "логин не работает" или "API иногда отвечает дважды", хотя причина находится в серверном middleware.