Вопрос проверяет понимание жизненного цикла context, отмены операций и архитектурных принципов передачи контекста.
context.Context предназначен для передачи через параметры функций, а не для хранения в структурах. Хранение контекста приводит к утечкам, неправильному времени жизни и сложным багам с отменой операций. Контекст должен отражать текущий запрос, а не жить дольше него.
context.Context в Go используется для управления временем жизни операций: отмены, таймауты, дедлайны и request-scoped данные. Его ключевая идея — контекст живёт столько же, сколько запрос или операция.
Когда context.Context кладут в структуру:
теряется контроль над временем жизни контекста;
структура может пережить запрос, но контекст — уже отменён;
невозможно понять, кто и когда обязан вызывать cancel;
появляется риск утечек горутин, ожидающих ctx.Done().
Контекст должен передаваться явно сверху вниз по стеку вызовов:
func (s *Service) Handle(ctx context.Context, req Request) error {
return s.repo.Save(ctx, req)
}Исключение — крайне редкие инфраструктурные случаи (например, root-context приложения), но даже там обычно используют локальные переменные, а не поля структур.
Вывод: context.Context передаётся параметром, не хранится в структурах и не используется как долгоживущая зависимость.
