Какие проблемы возникают при использовании static в C#

Что проверяют

Понимаете ли вы, что статика это глобальное состояние со всеми его последствиями, а не просто способ не создавать объект.

Как отвечать

Проблемы делятся на несколько групп.

Тестируемость. Статический метод нельзя подменить заглушкой: его нельзя передать через интерфейс и нельзя внедрить. Класс, вызывающий SomeHelper.Do(), жёстко связан с реализацией, и тест приходится писать либо с реальной зависимостью, либо через обёртку. Отсюда предпочтение внедрения зависимостей.

Время жизни. Статическое поле живёт до выгрузки домена приложения. Кэш в статической коллекции без вытеснения это утечка памяти, и она не проявится на разработческой машине.

Потокобезопасность. Статика по определению общая для всех потоков. В веб-приложении каждый запрос это отдельный поток, поэтому изменяемое статическое поле почти всегда гонка. static не даёт никаких гарантий синхронизации.

Статический конструктор. Выполняется один раз при первом обращении, но момент этот неявный. Исключение из него превращается в TypeInitializationException, и восстановить тип уже нельзя: любое следующее обращение снова упадёт. Плюс возможна взаимная блокировка при перекрёстной инициализации двух типов.

Наследование и полиморфизм. Статический член нельзя переопределить и нельзя вынести в интерфейс (до появления статических абстрактных членов в C# 11 с обобщениями).

Где статика уместна: чистые функции без состояния, константы, методы расширения, readonly значения.

Где спотыкаются

Считают статический класс просто удобным контейнером и складывают туда состояние.

Держат HttpClient статически и не понимают, что это как раз рекомендованный случай, но с оговорками про DNS.

Используют Lazy<T> неправильно и получают повторную инициализацию.

Не отличают static readonly от const: второе вшивается в вызывающие сборки на этапе компиляции.