Prácticas recomendadas para gopls y herramientas de análisis
La inteligencia del editor y los analizadores de CI deben contar la misma historia: retroalimentación rápida mientras se escribe, verificaciones autorizadas antes de la fusión.
//
Busca en todas las páginas de la documentación
La inteligencia del editor y los analizadores de CI deben contar la misma historia: retroalimentación rápida mientras se escribe, verificaciones autorizadas antes de la fusión.
Estas prácticas mantienen gopls, Delve y los linters alineados entre portátiles y canalizaciones.
.golangci.yml y YAML de CI.go.work en el editor, no una carpeta principal. gopls necesita go.mod (o espacio de trabajo) en la raíz del espacio de trabajo para obtener importaciones y diagnósticos correctos.gopls y go actualizadas según la política del equipo. Las discrepancias producen errores espurios o características faltantes.buildFlags o GOFLAGS para que los archivos etiquetados se compilen de la misma manera localmente y en las canalizaciones.gofumpt cuando el equipo se estandarice en él. El formato coherente elimina el ruido de las diferencias y las revisiones.dlv) junto con gopls para cada ingeniero backend. Depurar goroutines es una habilidad central, no una herramienta solo para escalada.dlv test para pruebas fallidas antes de agregar depuración con println. Deténgase en la línea de aserción e inspeccione las pilas de goroutines.-ldflags="-s -w" en las imágenes a las que se adjunte..golangci.yml en la raíz del repositorio y ejecute la misma configuración localmente. La deriva entre el portátil y la CI erosiona la confianza en los trabajos de lint.go test ./..., go vet ./... y govulncheck ./... en cada PR. Las pruebas detectan el comportamiento; vet y govulncheck detectan clases de fallos distintas.new-from-rev) en repositorios brownfield. La tolerancia cero desde el primer día hace que los equipos deshabiliten la CI.*.pb.go, vendor) del lint, no los paquetes escritos a mano. El ruido generado entrena a las personas a ignorar los hallazgos.//nolint genéricos. Requiera el nombre del linter, el ticket y la aprobación del revisor para las excepciones.go/analysis solo cuando sean objetivos. El gusto subjetivo permanece en la guía de revisión hasta que sea verificable por máquina.analysistest antes de habilitarlos en CI. Los linters no probados crean rotación de falsos positivos.tools/ con el mismo nivel de revisión que el código de producción. Los linters son parte de la superficie de calidad del producto.test, vet, golangci-lint, govulncheck). Un objetivo Makefile o mage supera el conocimiento tribal.Deben superponerse en el compilador y las comprobaciones de alto valor.
La CI puede ejecutar más analizadores; eso es esperado.
Alinee las configuraciones para minimizar sorpresas.
go test, go vet, staticcheck (a través de golangci-lint) y govulncheck.
Agregue gosec y nilaway según lo requiera el modelo de amenazas.
Use issues.new-from-rev y corrija los paquetes de forma incremental.
Rastree la reducción como cualquier otra tarea de ingeniería.
Las CLIs todavía se bloquean, manejan mal los errores y entran en pánico.
Delve sigue siendo valioso para cualquier concurrencia o estado no trivial.
Cuando la misma violación objetiva aparece en muchos PRs y ningún linter externo encaja.
Mantenga la regla estrecha y probada.
Ejecute en cada rama de PR.
Los escaneos solo en main permiten que las vulnerabilidades aterricen antes de la primera ejecución nocturna.
Analice cada módulo desde su raíz go.mod o documente un meta-script.
Comparta una plantilla .golangci.yml en todos los servicios donde las políticas coincidan.
Dependabot carece de alcance específico de Go.
Mantenga govulncheck como la puerta de enlace autorizada de CVE de módulos Go.
Cualquier cliente LSP con gopls está bien.
Estandarice la configuración y la ruta (PATH), no necesariamente la marca del IDE.
Señáleles las bases de configuración de herramientas de Go, confirme ejemplos de configuración del editor y proporcione un comando make check de un solo comando.
Versiones de pila: Esta página fue escrita para Go 1.26.x (predeterminado de Green Tea GC, go fix modernizers - verifique el parche en la compilación), chi (última versión - verifique en la compilación), gin (última versión - verifique en la compilación), echo (última versión - verifique en la compilación), google.golang.org/grpc (última versión - verifique en la compilación), sigs.k8s.io/controller-runtime (última versión - verifique en la compilación), kubebuilder (última versión - verifique en la compilación), tinygo (última versión - verifique los objetivos de la placa en la compilación), wazero (última versión - verifique en la compilación) y golangci-lint (última versión - verifique el conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 18 jul 2026