Boas Práticas de gopls & Ferramentas de Análise
A inteligência do editor e os analisadores de CI devem contar a mesma história: feedback rápido ao digitar, verificações autoritativas antes do merge.
//
Busque em todas as páginas da documentação
A inteligência do editor e os analisadores de CI devem contar a mesma história: feedback rápido ao digitar, verificações autoritativas antes do merge.
Estas práticas mantêm gopls, Delve e linters alinhados entre laptops e pipelines.
.golangci.yml e YAML da CI.go.work no editor, não uma pasta pai. O gopls precisa do go.mod (ou workspace) na raiz do workspace para imports e diagnósticos corretos.gopls e go atualizadas dentro da política da equipe. Discrepâncias produzem erros espúrios ou recursos ausentes.buildFlags ou GOFLAGS para que os arquivos com tags sejam verificados da mesma forma localmente e nos pipelines.gofumpt quando a equipe se padronizar nele. A formatação consistente remove ruído das diffs e revisões.dlv) junto com o gopls para todos os engenheiros de backend. Depurar goroutines é uma habilidade central, não uma ferramenta apenas para escalonamento.dlv test para testes com falha antes de adicionar depuração com println. Pare na linha da asserção e inspecione as pilhas de goroutines.-ldflags="-s -w" em imagens às quais você se anexa..golangci.yml na raiz do repositório e execute a mesma configuração localmente. A deriva entre o laptop e a CI erode a confiança nos trabalhos de lint.go test ./..., go vet ./... e govulncheck ./... em cada PR. Testes capturam comportamento; vet e govulncheck capturam classes distintas de falha.new-from-rev) em repositórios brownfield. Tolerância zero no primeiro dia faz com que as equipes desabilitem a CI.*.pb.go, vendor) de lint, não pacotes escritos à mão. Ruído gerado treina as pessoas a ignorar achados.//nolint. Exija o nome do linter, ticket e aprovação do revisor para exceções.go/analysis apenas quando objetivos. Gosto subjetivo permanece no guia de revisão até que seja verificável por máquina.analysistest antes de habilitá-los na CI. Linters não testados criam ruído de falsos positivos.tools/ com o mesmo padrão de revisão do código de produção. Linters fazem parte da superfície de qualidade do produto.test, vet, golangci-lint, govulncheck). Um alvo Makefile ou mage supera o conhecimento tribal.Eles devem se sobrepor em verificações de compilador e de alto valor.
A CI pode executar mais analisadores - isso é esperado.
Alinhe as configurações para minimizar surpresas.
go test, go vet, staticcheck (via golangci-lint) e govulncheck.
Adicione gosec e nilaway conforme o modelo de ameaça exigir.
Use issues.new-from-rev e corrija pacotes incrementalmente.
Acompanhe o burn-down como qualquer outra tarefa de engenharia.
CLIs ainda podem ter deadlocks, lidar mal com erros e entrar em pânico.
O Delve continua valioso para qualquer concorrência ou estado não trivial.
Quando a mesma violação objetiva aparece em muitos PRs e nenhum linter upstream se encaixa.
Mantenha a regra restrita e testada.
Execute em cada branch de PR.
Varreduras apenas em main permitem que vulnerabilidades cheguem antes do primeiro processamento noturno.
Faça lint de cada módulo a partir de sua raiz go.mod ou documente um meta-script.
Compartilhe um template .golangci.yml entre serviços onde as políticas correspondem.
O Dependabot não tem alcance específico para Go.
Mantenha o govulncheck como o portão autoritativo de CVEs de módulos Go.
Qualquer cliente LSP com gopls serve.
Padronize configurações e PATH, não necessariamente a marca do IDE.
Indique-os para as Noções Básicas de Configuração de Ferramentas Go, comite amostras de configurações de editor e forneça um comando make check único.
Versões de Stack: Esta página foi escrita para Go 1.26.x (padrão Green Tea GC, go fix modernizers - verifique o patch na compilação), chi (última versão - verifique na compilação), gin (última versão - verifique na compilação), echo (última versão - verifique na compilação), google.golang.org/grpc (última versão - verifique na compilação), sigs.k8s.io/controller-runtime (última versão - verifique na compilação), kubebuilder (última versão - verifique na compilação), tinygo (última versão - verifique os alvos de placa na compilação), wazero (última versão - verifique na compilação) e golangci-lint (última versão - verifique o conjunto de linters na compilação).
Revisado por Chris St. John·Última atualização: 18 de jul. de 2026