В чём разница между scope'ами @Injectable(): DEFAULT, REQUEST и TRANSIENT?

DEFAULT (Singleton)

Один экземпляр на всё приложение. Создаётся при старте, живёт до остановки сервиса. Это поведение по умолчанию.

import { Injectable } from '@nestjs/common';

@Injectable() // scope: Scope.DEFAULT — неявно
export class CacheService {
  private readonly store = new Map<string, string>();

  set(key: string, value: string) { this.store.set(key, value); }
  get(key: string) { return this.store.get(key); }
}

Область применения: соединения с БД, HTTP-клиенты, глобальный кэш, конфигурация. Производительность максимальная — экземпляр создаётся один раз.

Scopes провайдеров в NestJS: DEFAULT, REQUEST, TRANSIENT

Scope определяет жизненный цикл экземпляра провайдера — когда он создаётся и сколько живёт. Выбор scope напрямую влияет на производительность, изоляцию данных между запросами и потребление памяти.

REQUEST

Новый экземпляр на каждый входящий запрос. Экземпляр существует от получения запроса до отправки ответа. После завершения — сборщик мусора утилизирует его.

import { Injectable, Scope } from '@nestjs/common';

@Injectable({ scope: Scope.REQUEST })
export class RequestContextService {
  private userId: string;

  setUserId(id: string) { this.userId = id; }
  getUserId(): string { return this.userId; }
}

Важно: если REQUEST-scoped провайдер инжектируется в DEFAULT-scoped провайдер, NestJS автоматически повышает scope «заражённого» провайдера до REQUEST. Это называется scope propagation (bubble-up).

@Injectable() // станет REQUEST из-за зависимости
export class OrderService {
  constructor(private readonly ctx: RequestContextService) {} // REQUEST scope
}

Доступ к объекту запроса внутри REQUEST-scoped провайдера:

import { Inject, Injectable, Scope } from '@nestjs/common';
import { REQUEST } from '@nestjs/core';
import { Request } from 'express';

@Injectable({ scope: Scope.REQUEST })
export class TenantService {
  constructor(@Inject(REQUEST) private readonly request: Request) {}

  getTenantId(): string {
    return this.request.headers['x-tenant-id'] as string;
  }
}

TRANSIENT

Новый экземпляр для каждой точки инжекции. Если один провайдер инжектируется в три разных места — создаются три независимых экземпляра.

import { Injectable, Scope } from '@nestjs/common';

@Injectable({ scope: Scope.TRANSIENT })
export class LoggerService {
  private context: string = 'App';

  setContext(ctx: string) { this.context = ctx; }
  log(msg: string) { console.log(`[${this.context}] ${msg}`); }
}

// UserService получит свой экземпляр LoggerService
@Injectable()
export class UserService {
  constructor(private readonly logger: LoggerService) {
    this.logger.setContext('UserService');
  }
}

// OrderService получит другой экземпляр LoggerService
@Injectable()
export class OrderService {
  constructor(private readonly logger: LoggerService) {
    this.logger.setContext('OrderService');
  }
}

Сравнительная таблица

• DEFAULT: создаётся 1 раз, живёт вечно, нет изоляции между запросами. Производительность: максимальная.
• REQUEST: создаётся на каждый запрос, живёт в пределах запроса, полная изоляция. Производительность: умеренная (GC нагрузка).
• TRANSIENT: создаётся на каждую инжекцию, нет изоляции на уровне запроса. Производительность: наихудшая при частых инжекциях.

Подводные камни

• REQUEST scope «заражает» всю цепочку зависимостей вверх — неожиданное повышение scope singleton-сервиса до REQUEST убивает производительность.
• Websockets и микросервисы не поддерживают REQUEST scope в полном смысле — контекст запроса отсутствует.
• TRANSIENT не создаёт изоляцию между запросами: состояние транзиентного провайдера не изолировано между разными HTTP-запросами.
• Mutable singleton state опасен при конкурентности: если DEFAULT-провайдер хранит mutable поле без синхронизации, возможны race conditions.
• REQUEST scope в высоконагруженных API (>1000 RPS) создаёт тысячи экземпляров в секунду — profile heap перед деплоем.
• Circular dependency между REQUEST-scoped провайдерами приводит к runtime ошибке, не к compile-time — добавить `forwardRef()` осторожно.
• При использовании `REQUEST` провайдера в Guards или Interceptors убедиться, что они зарегистрированы через DI (не через `new`).

• Дает общий ответ про Node.js и не называет конкретные API NestJS.
• Не объясняет, где в lifecycle находится scope'ы Injectable.
• Не разделяет validation, authorization, business logic и persistence.
• Игнорирует ошибки, лимиты входных данных, observability и тестирование.

• Может объяснить scope'ы Injectable на примере кода.
• Называет ключевые API: Scope.DEFAULT, Scope.REQUEST, Scope.TRANSIENT.
• Использует точные API NestJS, а не вымышленные hooks/decorators/methods.
• Видит production-риски: безопасность, отказоустойчивость, логирование и тесты.