Какие фреймворки для Go предпочитаешь

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

Знаете ли вы экосистему и понимаете ли её культуру: в Go принято собирать сервис из стандартной библиотеки и небольших пакетов, а не брать тяжёлый фреймворк. Следом обычно спрашивают, зачем вообще фреймворк после изменений в net/http в Go 1.22.

Как отвечать

Начните с того, что считаете базой, и объясните выбор:

• net/http: с Go 1.22 стандартный ServeMux понимает метод и параметры в шаблоне (GET /users/{id}, значение через r.PathValue("id")). Для небольшого API этого хватает;
• chi: лёгкий роутер поверх net/http с группами маршрутов и middleware, обработчики остаются обычными http.Handler;
• Gin: самый популярный фреймворк, свой *gin.Context, биндинг и валидация запросов через теги структур;
• Echo: близок к Gin по возможностям, обработчик возвращает error, и ошибки собираются в одном месте;
• Fiber: построен на fasthttp, а не на net/http. Быстр на синтетике, но без адаптера несовместим со стандартными middleware и не умеет HTTP/2.

Рядом назовите grpc-go или Connect для межсервисного взаимодействия, pgx, sqlc или sqlx для базы, а про GORM честно скажите, что многие Go-команды относятся к ORM настороженно.

Лучший формат ответа: «в последнем проекте был chi, потому что...», и чем в этом случае проиграл бы Gin. Если работали только с одним инструментом, так и скажите и покажите, что понимаете устройство остальных. Истории вида «сменили фреймворк, и всё ускорилось» без профилирования лучше не рассказывать: на реальном сервисе время ответа почти всегда съедают база и сеть, а не роутер.

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

Выбирают Fiber по бенчмаркам, не зная, что он живёт вне net/http, а потом не могут подключить привычные библиотеки трассировки и middleware.

Не слышали про новый роутинг в стандартной библиотеке и тащат фреймворк ради одного параметра в пути.

Называют Beego или Revel актуальным выбором. Упомянуть их можно, но в новых проектах они редки, и интервьюер ждёт объяснения, почему команды ушли от «полного стека» к набору библиотек.