Какие линтеры используешь в работе

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

Есть ли у вас рабочая настройка статического анализа, а не список названий. Следом спрашивают, как это встроено в CI и что вы делаете с ложными срабатываниями.

Как отвечать

Начните с того, что часть инструментов идёт в самом тулчейне Go:

• gofmt и goimports: форматирование и порядок импортов, спорить о стиле не приходится. Строже gofumpt;
• go vet: подозрительные конструкции вроде неверного формата в Printf, копирования sync.Mutex по значению, недостижимого кода. Часть его проверок запускается сама при go test;
• staticcheck: самый полезный отдельный анализатор. Находит неиспользуемый код, устаревшие API, defer внутри цикла, лишние конструкции.

На практике всё собирают в golangci-lint, который гоняет десятки линтеров за один проход с общим кешем. В v2 сменился формат конфига (version: "2" в .golangci.yml), форматтеры вынесены в отдельный раздел, а gosimple и stylecheck вошли в staticcheck. Стандартный набор: errcheck, govet, ineffassign, staticcheck, unused. Поверх него обычно включают:

• revive: стиль и именование, замена устаревшего golint;
• gosec: SQL из конкатенации, слабая криптография, права на файлы;
• errorlint: сравнение ошибок через == вместо errors.Is;
• bodyclose: незакрытый resp.Body в HTTP-клиенте.

Расскажите про процесс: подсветка в IDE через gopls, обязательный шаг в CI, а в старом проекте --new-from-rev, чтобы проверять только новый код. Уязвимости в зависимостях ловит govulncheck, это отдельный инструмент.

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

Называют golint основным инструментом. Он давно заархивирован, и упоминание без оговорки выдаёт устаревшие знания.

Включают enable-all и тонут в шуме, после чего команда массово ставит //nolint. Каждое подавление должно называть конкретный линтер и причину.

Путают форматтер с линтером и ждут, что gofmt найдёт ошибку. Он меняет только внешний вид кода, логику проверяют go vet и staticcheck.