Какие плюсы и минусы React Context?

React Context — встроенный способ передавать данные через дерево без prop drilling. У него чёткий набор сильных и слабых сторон.

Плюсы

• Встроен в React — ноль зависимостей, ноль настройки: createContext + Provider + useContext.
• Решает prop drilling — данные доступны на любой глубине без транзитных props.
• Область действия по поддереву — разные ветки могут иметь разные значения (вложенные провайдеры); удобно для тем, форм, составных компонентов.
• Тестируемость и DI — в тестах компонент оборачивается провайдером с моками; контекст — простой способ инъекции сервисов (api-клиент, аналитика).
• Типизируется в TypeScript, работает с SSR.

Минусы

• Все потребители рендерятся при любом изменении value — селекторов «на кусочек» нет; для часто меняющихся данных это удар по производительности.
• Нестабильный value — классическая ловушка: value={{ user, logout }} создаёт новый объект каждый рендер провайдера и будит всех; нужен useMemo.
• Нет инструментов — ни девтулзов с историей изменений, ни middleware, ни time travel.
• Неявная зависимость — компонент с useContext не покажет в сигнатуре, что ему нужно; без провайдера сверху получит default (часто молчаливый баг — принято кидать ошибку из кастомного хука useXxx).
• Логика обновлений не централизована (в отличие от редьюсеров стора).

Практика применения

Тема, локаль, пользователь, конфиг, сервисы — да. Часто меняющееся состояние, сложный стор — нет (Zustand/Redux). Смягчение минусов: мемоизированный value, разделение контекстов (данные/действия, быстрые/медленные), кастомный хук с проверкой наличия провайдера.

Коротко для собеседования

Плюсы Context: встроен, убирает prop drilling, скоупится по поддереву, удобен для DI и тестов. Минусы: перерендер всех потребителей без селекторов, ловушка нестабильного value, нет девтулзов, неявные зависимости. Годится для редко меняющегося «окружения», не годится как стейт-менеджер.