¿Por qué go mod init de Go 1.26 escribe una versión inferior por defecto?

Enunciado y contexto

Un proyecto utiliza Go 1.26 para inicializar un nuevo módulo. El go.mod generado puede contener go 1.25.0. Explique el efecto en la compilación, la resolución de dependencias y CI, y luego proponga un plan de actualización seguro.

Qué evalúa el entrevistador

• Separar la versión de la toolchain, la directiva go y los mínimos de las dependencias.
• Explicar los beneficios de compatibilidad y el límite en torno a las nuevas características del lenguaje.
• Diseñar una actualización de módulo verificable y reversible.

Preguntas de aclaración

• ¿Debe el servicio seguir siendo compatible con una toolchain compatible más antigua, o usar características de Go 1.26 ahora?
• ¿Están producción, desarrollo y CI anclados a la misma toolchain?
• ¿Declara alguna dependencia una versión mínima de Go superior?

Respuesta en 30 segundos

Go 1.26 hace que go mod init elija una directiva go inferior para que los módulos nuevos sigan siendo compatibles con las toolchains soportadas. Esa directiva no es el compilador que realmente ejecuta la compilación, y no hace que las API exclusivas de Go 1.26 estén disponibles para compiladores más antiguos. Confirmaría el objetivo de compatibilidad, fijaría la toolchain en CI, ejecutaría explícitamente go get go@version o editaría go.mod, y luego ejecutaría pruebas, go mod tidy y compilaciones con la versión mínima soportada antes del lanzamiento.

Solución paso a paso

1. La directiva go registra la semántica mínima del lenguaje y de la toolchain para el módulo; el binario de Go instalado es el ejecutor.
2. Una toolchain estable de Go 1.26 inicializa un módulo con go 1.25.0; las toolchains de versión preliminar eligen una versión anterior. Esto evita excluir toolchains compatibles por accidente.
3. Si el código necesita la sintaxis de Go 1.26 o las API de la biblioteca estándar, aumente el mínimo explícitamente y alinee CI, los contenedores de desarrollo y las imágenes de lanzamiento.
4. Después de go mod init, use go get go@1.26.0 cuando se busque un requisito de toolchain explícito. No cambie una sola línea ignorando el grafo de dependencias.
5. Ejecute go test ./..., go vet ./... y compilaciones en las versiones mínima y más reciente compatibles; incluya código generado, build tags y plataformas de destino.
6. Revise go.mod, go.sum y los metadatos de compilación reproducible. Si la validación falla, revierta el cambio de versión y vuelva a ejecutar las comprobaciones.

Respuesta modelo

Separo el "uso de Go 1.26" en la toolchain en ejecución, el mínimo del módulo y los mínimos de las dependencias. El valor predeterminado inferior de go mod init es una política de compatibilidad: permite que un módulo nuevo apunte a una toolchain aún compatible; no cambia producción a Go 1.25. Si el servicio depende de una capacidad del lenguaje o de la biblioteca estándar de Go 1.26, aumentaría la directiva go con go get go@1.26.0, fijaría la misma toolchain en CI y revisaría el grafo de dependencias. Condicionaría el cambio a compilaciones con la versión mínima, pruebas en la versión más reciente, go mod tidy, compilación multiplataforma y comprobaciones de dependencias, manteniendo a la vez un commit de reversión versionado.

Errores comunes

• Tratar go 1.25.0 como una configuración de tiempo de ejecución que fuerza Go 1.25.
• Actualizar una laptop pero no CI, los contenedores o los trabajos de release.
• Editar go.mod sin go mod tidy y sin una compilación en la versión mínima.
• Pasar por alto una dependencia que requiere una versión de Go superior.

Preguntas de seguimiento y respuestas

El equipo aún debe admitir Go 1.25. ¿Puede usar una API de Go 1.26?

No en código compilado por Go 1.25. Utilice build tags, un adaptador de interfaz o una implementación diferente, y pruebe ambas versiones explícitamente.

¿Qué cambia go get go@1.26.0?

Actualiza el requisito de la toolchain de Go del módulo. Los go.mod, go.sum y cambios de dependencias resultantes aún necesitan revisión; el comando no es una aprobación de compatibilidad.

Una dependencia requiere Go 1.26 pero el servicio apunta a 1.25. ¿Qué sigue?

Busque una versión de dependencia compatible o un reemplazo. Si la dependencia es esencial, aumente el mínimo del servicio y actualice las imágenes, CI y los procedimientos de reversión de forma conjunta.

¿Cómo demuestra que el comportamiento no cambió?

Compare los resultados de pruebas unitarias, de integración, de carreras (race), de benchmarks y multiplataforma en la toolchain mínima y en la más reciente, y luego inspeccione los artefactos y las métricas del servicio contra una línea base.