El Comando Go: Ciclo de Vida de Compilación, Pruebas y Módulos
El comando go es el controlador unificado de Go para compilar programas, ejecutar pruebas, gestionar módulos y aplicar verificaciones estáticas.
//
Busca en todas las páginas de la documentación
El comando go es el controlador unificado de Go para compilar programas, ejecutar pruebas, gestionar módulos y aplicar verificaciones estáticas.
En lugar de exponer un binario de compilador separado que invocas manualmente, el toolchain envuelve el compilador, enlazador, ensamblador y proxy de módulos en un flujo de trabajo que entiende las rutas de importación, las etiquetas de compilación y las fijaciones de versión.
Esta página es el ancla conceptual para la sección Go Toolchain.
Fundamentos de Go Toolchain recopila fragmentos de comandos ejecutables; los artículos hermanos cubren go build, mantenimiento de módulos, analizadores, etiquetas de compilación y compilación cruzada.
go convierte árboles de código fuente y requisitos de go.mod en acciones de compilación cacheadas, ejecuciones de pruebas y binarios instalables a través de un pipeline compartido de carga de paquetes y resolución de dependencias.Imagina el comando go como un gestor de proyectos que se sienta sobre tres sistemas cooperativos: el toolchain del compilador (compile, link, asm), el sistema de módulos (go.mod, proxies, base de datos de checksums) y la caché de compilación en disco.
Nombbras un patrón de paquete (./..., example.com/app/cmd/server) y el comando carga los paquetes coincidentes, resuelve las importaciones a versiones de módulos, aplica restricciones de compilación (SO, arquitectura, etiquetas personalizadas), y luego programa el trabajo como un grafo dirigido acíclico de acciones.
Cada acción puede compilar un paquete, enlazar un binario o ejecutar una prueba.
Los resultados exitosos se almacenan en GOCACHE para que las entradas sin cambios eviten reprocesos.
Los módulos responden a "¿qué versión de esta ruta de importación debo usar?".
Tu go.mod lista las directivas require; el toolchain calcula una lista de compilación con Selección de Versión Mínima (MVS), descarga módulos en la caché de módulos (GOMODCACHE) y verifica los hashes de archivos contra go.sum.
Esa separación significa que los paquetes son unidades de tiempo de compilación mientras que los módulos son unidades de distribución versionadas.
go build produce un artefacto en el directorio actual (o -o).
go run compila a un binario temporal y lo ejecuta.
go install coloca un binario en GOBIN o GOPATH/bin.
go test compila binarios de prueba (incluyendo archivos _test.go) y los ejecuta, opcionalmente con -race, -cover, o -bench.
Todos estos comparten la misma mitad frontal de carga y compilación; solo la acción final difiere.
Cuando ejecutas go test ./..., el comando recorre la raíz del módulo, expande ./... a cada paquete en el subárbol y construye un grafo de importación.
Para cada paquete, decide si las fuentes cambiaron hasheando las entradas (archivos, flags, versión del toolchain, etiquetas de compilación).
Los aciertos de caché cortocircuitan; los fallos ponen en cola acciones de compilación y enlace.
Las ejecuciones de pruebas añaden otra capa: el enlazador construye un main de prueba que registra las funciones Test*, luego el comando ejecuta ese binario y transmite los resultados.
Los comandos de mantenimiento de módulos (go mod tidy, go mod download, go mod vendor) operan sobre los mismos metadatos que usa la compilación.
tidy añade líneas require faltantes y elimina las no utilizadas escaneando las importaciones en tu módulo.
download calienta la caché de módulos sin compilar.
vendor copia las fuentes de los módulos a vendor/ para compilaciones sin conexión o auditadas (-mod=vendor).
GOTOOLCHAIN (Go 1.21+) selecciona qué release de Go ejecuta el comando.
Una línea go.mod como go 1.26 puede desencadenar la descarga automática de un toolchain más nuevo cuando GOTOOLCHAIN=auto (el predeterminado), manteniendo las releases de parches consistentes entre compañeros de equipo.
go test ./...
│
▼
carga paquetes + aplica etiquetas de compilación
│
▼
resuelve versiones de módulos (MVS) ──► verifica go.sum
│
▼
planifica grafo de acciones ──► ¿acierto GOCACHE? ──sí──► omite compilación
│ │
│ no
│ ▼
│ compilar / enlazar / ejecutar prueba
▼
resultados stdout + código de salida
// go.mod fija expectativas de lenguaje/toolchain
module example.com/widget
go 1.26
require golang.org/x/sync v0.10.0| Comando familia | Trabajo principal | Paso típico de CI |
|---|---|---|
go build / go install | Produce binarios | Artefacto de release |
go test | Ejecuta pruebas unitarias, de race, de bench | Puerta requerida |
go vet / go fix | Verificaciones estáticas y reescrituras | Etapa de lint |
go mod tidy | Normaliza dependencias | Después de PRs de dependencias |
go mod vendor | Vende fuentes | Builds air-gapped o por política |
go list -m all | Inspecciona lista de compilación | Auditoría / entrada SBOM |
Los pipelines de CI suelen encadenar go mod download (calentamiento de caché), go test -race ./..., go vet ./..., y staticcheck o golangci-lint para análisis más profundos.
Go 1.26 establece por defecto el recolector de basura Green Tea; haz benchmarks antes de cambiar GOGC basándote en suposiciones antiguas.
Los modernizadores de go fix reescriben patrones heredados (por ejemplo, capturas antiguas de variables de bucle) antes de la revisión humana.
Los módulos privados requieren GOPRIVATE y a menudo un proxy de módulos como Athens o Artifactory para que el proxy público nunca vea rutas internas.
La compilación cruzada establece GOOS y GOARCH (o usa go env -w localmente) para que un nodo de CI Linux construya artefactos de Darwin o Windows.
-trimpath y -ldflags "-s -w" reducen los binarios y eliminan las rutas del host de las pilas de pánico, lo que importa para revisiones de seguridad e imágenes de contenedores.
Cuando las compilaciones se sienten lentas, inspecciona la efectividad de la caché con go clean -cache solo como un paso de solución de problemas, no como un hábito diario.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Caché de módulos + proxy | Descargas rápidas y reproducibles | Necesita red o caché caliente | Flujo de trabajo predeterminado de código abierto |
| Vendoring | Árbol de código fuente auditable sin conexión | Fusión de cambios en actualizaciones | Entornos regulados o air-gapped |
GOTOOLCHAIN=local | Sin descarga automática de toolchain | Compañeros de equipo con Go antiguo rompen compilaciones | Mantenimiento de legado estrictamente fijado |
Espacio de trabajo (go.work) | Desarrollo local multi-módulo | Otro archivo para sincronizar en CI | Monorepos con bibliotecas compartidas |
| Caché de compilación remota (Bazel/CI) | Compartida entre máquinas | Infraestructura adicional | Organizaciones muy grandes |
go run es para despliegues de producción - siempre compila primero y usa un binario temporal; envía artefactos de go build en su lugar.go get solo descarga - en modo módulo también actualiza go.mod y puede actualizar requisitos transitivos.go.sum soluciona errores de checksum - generalmente enmascara manipulación o problemas de proxy; investiga la discrepancia en su lugar.go test solo ejecuta pruebas en el directorio actual - patrones como ./... recursan; olvidar eso omite paquetes en subcarpetas.go.mod - go.mod sigue siendo la autoridad; vendor/ es una instantánea materializada.GOROOT es el SDK de Go instalado (compilador, stdlib).
GOPATH es la raíz del espacio de trabajo heredado; el modo módulo almacena descargas en GOMODCACHE en lugar de GOPATH/src.
Los binarios de go install aterrizan en GOPATH/bin o GOBIN.
GOCACHE almacena los resultados de las acciones indexados por las entradas.
Los paquetes sin cambios reutilizan los archivos compilados en lugar de recompilar.
Cuando las importaciones referencian módulos no listados en require, o los require listados no se usan.
Ejecútalo después de refactors que añaden o eliminan importaciones.
Permite que el comando descargue y use un toolchain más nuevo que satisfaga la directiva go en go.mod.
Establece local para prohibir descargas automáticas.
Compila archivos que terminan en _test.go en el mismo paquete (o package foo_test para pruebas externas).
Solo las funciones llamadas TestXxx con la firma func TestXxx(t *testing.T) se registran.
Sí, con una caché de módulos caliente o un árbol vendor/ y compilaciones usando -mod=vendor.
La CI debe vender o cachear módulos explícitamente para trabajos herméticos.
El conjunto de versiones de módulos seleccionadas para una compilación después de que MVS resuelva todas las restricciones require.
Inspecciónala con go list -m all.
Sí.
Realiza la verificación de tipos de paquetes usando el mismo cargador que build y test, luego ejecuta pases de análisis.
go.mod declara la intención; go.sum registra hashes criptográficos del contenido del módulo en el momento de la descarga.
El toolchain rechaza archivos no coincidentes.
MVS elige la versión mínima que satisface cada require.
Aún puedes usar replace para excepciones.
go clean -testcache solo borra los resultados de las pruebas.
go clean -cache fuerza recompilaciones completas y debe ser deliberado, no por compilación.
Las etiquetas filtran qué archivos se compilan en un paquete.
Las pruebas en archivos protegidos por etiquetas se ejecutan solo cuando esas etiquetas están habilitadas con -tags.
Versiones de Stack: Esta página fue escrita para Go 1.26.x (Green Tea GC por defecto, modernizadores de go fix - verificar parche en la compilación), chi (última - verificar en la compilación), gin (última - verificar en la compilación), echo (última - verificar en la compilación), google.golang.org/grpc (última - verificar en la compilación), sigs.k8s.io/controller-runtime (última - verificar en la compilación), kubebuilder (última - verificar objetivos de placa en la compilación), tinygo (última - verificar objetivos de placa en la compilación), wazero (última - verificar en la compilación), y golangci-lint (última - verificar conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 19 jul 2026