Скоупы и время жизни DI: singleton, request, transient

Баг-репорт говорит: пользователь A иногда видит имя аккаунта пользователя B. Код auth корректен. Утечка — в поле currentUser на сервисе, зарегистрированном как синглтон — один экземпляр, разделяемый каждым параллельным запросом. Запрос A ставит поле, запрос B перезаписывает миллисекундой позже, и запрос A читает значение B. Никто не писал баг безопасности. Кто-то выбрал неверное время жизни.

Три времени жизни

DI-контейнер может создавать экземпляр с тремя ритмами:

• Singleton — один экземпляр на весь процесс, создан один раз и разделяем каждым запросом. Дефолт в NestJS, Spring и большинстве контейнеров. Быстро и легко по памяти, ведь ничего не пересоздаётся.
• Request-scoped — один экземпляр на входящий запрос, разделяем внутри этого запроса, выброшен после. Полезен для контекста на запрос (текущий пользователь, request ID, транзакция на запрос).
• Transient — свежий экземпляр на каждое внедрение. Полезен для stateful-помощников, которыми вообще нельзя делиться.

Ловушка «синглтон с состоянием»

Баг из Hook — каноническая ошибка синглтона: синглтон должен быть stateless относительно запроса, ведь он разделяем всеми параллельными запросами. Хранение this.currentUser на синглтоне — утечка данных, ждущая случиться: параллельные запросы гонятся за общим полем. Лечение — либо пустить данные на запрос через аргументы метода (передавать user, а не хранить), либо сделать сервис request-scoped, чтобы каждый запрос получал свой экземпляр.

Противоположная ловушка: всплытие скоупа

Request-скоуп выглядит безопасным дефолтом, и команды тянутся к нему — и платят скрытую цену. Скоуп всплывает вверх по цепочке внедрения: если request-scoped провайдер внедрён в контроллер, тот контроллер тоже становится request-scoped, и всё, что зависит от него. Один request-scoped логгер у самого низа может «заразить» весь граф выше, так что контейнер переинстанцирует большой срез ваших сервисов на каждом запросе вместо переиспользования синглтонов. Это лишние аллокации, лишнее давление на GC и измеримая задержка — ради того, что часто лишь удобство.

Выбор времени жизни

Правило, избегающее обеих ловушек: по умолчанию singleton и держи синглтоны stateless; тянись к request-скоупу лишь когда тебе вправду нужна идентичность на запрос, которую нельзя передать аргументом; используй transient экономно для намеренно неразделяемых stateful-помощников. Большинство случаев «мне нужен текущий пользователь здесь» лучше решаются передачей его через вызов, чем превращением сервиса в request-scoped и утягиванием всего графа вниз.