Buenas Prácticas de Filosofía de Go
Diez principios que mantienen las bases de código Go alineadas con el espíritu del lenguaje: legible, explícito y operable a escala.
//
Busca en todas las páginas de la documentación
Diez principios que mantienen las bases de código Go alineadas con el espíritu del lenguaje: legible, explícito y operable a escala.
go fix en 1.26 son un buen disparador).golangci-lint, go vet) para que la filosofía se convierta en una señal de CI, no en memoria.gofmt se encargue del formato. No debates de alineación personalizados en revisiones; usa gofmt/goimports en CI.checkout sobre util.UserStore es mejor que UserDAO; Go no es cosplay empresarial de Java.context.Context como el primer parámetro en los límites de E/S. Nunca almacenes contexto en structs.(T, error) y envuelve con %w. Documenta errores centinela con var ErrFoo = errors.New("...") para errors.Is estables.New en main. Evita var db *sql.DB globales en bibliotecas; conéctalas explícitamente en cmd/.ctx.Done() y evita la expansión ilimitada.go test -race en CI en paquetes que usan goroutines. La filosofía sin detección es pensar en vano.net/http, encoding/json y log/slog cubren muchos servicios.pprof, trazador de ejecución). Medir se alinea con la cultura de Go; adivinar no.SIGTERM, vacía los manejadores y alinéate con la semántica de las sondas de Kubernetes.go fix durante las actualizaciones. Deja que las herramientas migren los modismos en lugar de cambios manuales en monorepos.govulncheck. La filosofía incluye la higiene de la cadena de suministro, no solo la sintaxis./v2.El título refleja el decálogo cultural central; las secciones agrupan reglas aplicables relacionadas.
Adopta toda la lista aunque el marketing redondee a diez temas.
Aplica gofmt, go vet, golangci-lint, -race y govulncheck en CI.
Los límites de los paquetes y la forma de las APIs se mantienen en la revisión humana con respaldo de ADR.
Los frameworks están bien cuando eliminan código repetitivo sin ocultar el ciclo de vida.
La filosofía todavía exige una conexión explícita, contexto y apagado en main.
Sí para concurrencia, contexto y errores.
El código interno puede avanzar más rápido en cambios disruptivos, pero prefiere límites de módulos claros de todos modos.
Importar patrones empresariales de Java/C# —gráficos de DI gigantes, interfaces amplias y errores basados en strings— que la cadena de herramientas de Go no recompensa.
Usa genéricos para eliminar duplicaciones, no para construir frameworks genéricos.
Si func Map es más claro sin parámetros de tipo, sáltatelos.
Cuando los frameworks proporcionan ecosistemas de middleware probados (autenticación, enlazado, hooks de OpenTelemetry) que tardarían trimestres en replicarse.
Documenta la dependencia en un ADR.
Incorpora a cada ingeniero, revisa durante las actualizaciones importantes de Go y después de incidentes causados por deriva de concurrencia o API.
Las reglas de concurrencia y contexto todavía se aplican donde el tiempo de ejecución las soporta.
Las restricciones de memoria y syscall pueden requerir dependencias más ligeras; verifica los objetivos de la placa en la compilación.
Bucles de reconciliación explícitos, llamadas a cliente conscientes del contexto, registro estructurado y apagado de elección de líder reflejan las reglas del servicio.
Usa patrones de controller-runtime en lugar de inventar pegamento de observación.
Menores tasas de incidentes por pánicos/carreras, encuestas de incorporación más rápidas, menos cambios de API disruptivos y PRs de actualización dominados por herramientas (go fix) en lugar de ediciones manuales.
Pasa a las secciones de fundamentos, concurrencia y arquitectura una vez que las normas del equipo estén alineadas.
Versiones de Stack: Esta página fue escrita para Go 1.26.x (GC Green Tea por defecto, modernizadores go fix - verifica el parche en la compilación), chi (última versión - verifica en la compilación), gin (última versión - verifica en la compilación), echo (última versión - verifica en la compilación), google.golang.org/grpc (última versión - verifica en la compilación), sigs.k8s.io/controller-runtime (última versión - verifica en la compilación), kubebuilder (última versión - verifica en la compilación), tinygo (última versión - verifica objetivos de placa en la compilación), wazero (última versión - verifica en la compilación), y golangci-lint (última versión - verifica el conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 18 jul 2026