Si programas en Go y usas sistemas distribuidos, APIs o bases de datos, casi con certeza tienes github.com/google/uuid en tu go.mod. Eso podría estar a punto de cambiar: la propuesta oficial para añadir un paquete crypto/uuid a la biblioteca estándar de Go tiene estatus Likely Accept en el repositorio oficial, con actualizaciones activas en febrero de 2026. Es la primera vez en años que el equipo central del lenguaje se acerca tanto a incorporar esta funcionalidad tan básica.
No es solo comodidad. Hay un argumento de seguridad muy concreto, y también uno de arquitectura. Acá te cuento qué propone el cambio, qué implica en la práctica y por qué el timing importa.
¿Por qué Go no tenía UUID nativo hasta ahora?
Durante años, la respuesta oficial del equipo de Go fue que el ecosistema de terceros cubría bien esta necesidad. github.com/google/uuid se consolidó como el estándar de facto: más de 5.800 estrellas en GitHub y una dependencia activa de más de 434.000 paquetes. Pero esa concentración, paradójicamente, creó un problema nuevo.
En diciembre de 2025, el equipo de investigación de Socket descubrió dos paquetes maliciosos en el ecosistema Go que se hacían pasar por google/uuid. Habían estado activos desde 2021. Su función: convertir llamadas aparentemente inocentes en canales cifrados de exfiltración de datos hacia servicios externos. El ataque se conoce como typosquatting, y fue posible precisamente porque no existe una versión oficial y canónica del paquete en la stdlib.
Hay un segundo problema: inestabilidad histórica. satori/go.uuid introdujo cambios de API sin advertencia que rompieron frameworks enteros. google/uuid desaceleró su mantenimiento desde 2025. Para equipos que usan UUIDs en operaciones críticas de producción, esa incertidumbre no es aceptable.
Qué propone crypto/uuid: los detalles técnicos
La propuesta principal es la #62026, presentada en agosto de 2023 y con refinamientos activos a cargo de neild, miembro del equipo de Go. Su objetivo: un paquete crypto/uuid que cubra el estándar RFC 9562 —la evolución moderna del RFC 4122—. Los puntos clave:
- UUIDv4: generación aleatoria usando
crypto/rand. El estándar de facto para identificadores de uso general. - UUIDv7: basado en timestamp Unix con alta entropía. Ideal para usar como clave primaria en bases de datos porque mantiene ordenación temporal, mejorando dramáticamente el rendimiento de índices B-tree y reduciendo la fragmentación en PostgreSQL, MySQL o CockroachDB.
- Parse: una función más permisiva que las implementaciones actuales, capaz de manejar variantes del formato estándar
xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx. - Constantes Nil y Max: ambas referenciadas explícitamente en el RFC 9562.
- Función Compare: para comparación determinista entre UUIDs.
- Tipo de datos:
[16]bytefijo, garantizando type safety sin la ambigüedad de los byte slices.
También existió una propuesta paralela (#76319) más conservadora: solo añadir generación de UUIDv4 y UUIDv7 dentro del paquete crypto/rand existente, sin parsing ni funciones auxiliares. Esa propuesta fue cerrada. La señal es clara: el equipo de Go prefiere la solución completa.
¿Qué cambia si migras desde google/uuid?
La transición está diseñada para ser lo menos dolorosa posible. El diseño de la API propuesta en #62026 es deliberadamente similar al de google/uuid, y los beneficios son concretos:
- Cero dependencias externas: eliminas una entrada de
go.mody reduces la superficie de ataque de tu cadena de suministro de software de forma permanente. - Go 1 Compatibility Promise: el equipo central de Go asume la responsabilidad de mantenimiento. No más preocupaciones sobre si el mantenedor del paquete va a tener tiempo esta semana.
- RFC 9562 nativo: soporte formal para UUIDv7, que sigue siendo mal soportado en varios paquetes de terceros.
- Auditorías más limpias: en contextos regulados —fintech, healthtech, cualquier entorno con auditorías de seguridad— reducir dependencias externas simplifica el proceso considerablemente.
El caso especial de UUIDv7 en bases de datos
Merece párrafo aparte. Si usas UUIDs como claves primarias (un patrón muy común en microservicios y APIs REST), el UUIDv4 tiene un problema estructural: es completamente aleatorio, lo que genera fragmentación de índice B-tree en cualquier base de datos relacional. Cada INSERT termina escribiendo en una posición aleatoria del índice, forzando splits y rebalanceos constantes.
El UUIDv7 resuelve esto incorporando un timestamp de alta resolución en los bits más significativos. Los registros nuevos siempre se insertan al final del índice —como lo haría un AUTOINCREMENT entero— sin perder las propiedades de unicidad global que hacen útil al UUID en primer lugar. Para sistemas de alto volumen de escritura, la diferencia de rendimiento puede ser de órdenes de magnitud.
Tener UUIDv7 en la stdlib de Go elimina la fricción actual de elegir entre tres o cuatro implementaciones de terceros con diferentes niveles de madurez y compatibilidad.
Estado actual: ¿cuándo llega?
La propuesta #62026 tiene estatus Likely Accept en el repositorio oficial. Eso no significa que ya esté aprobada: todavía puede ser rechazada o modificada. Pero es el paso previo formal a la aceptación, y los refinamientos activos de febrero de 2026 por parte del equipo central sugieren momentum real.
Go tiene ciclos de release semestrales. Go 1.23 salió en agosto de 2024; Go 1.24 en principios de 2025. Si la aceptación formal ocurre en los próximos meses, la comunidad anticipa disponibilidad en Go 1.25 o Go 1.26. No hay fecha garantizada, pero la dirección es inequívoca.
Lo que sí es seguro: la propuesta paralela más conservadora (#76319) fue descartada, lo que refuerza que cuando llegue el paquete, llegará completo.
Por qué importa
La historia de crypto/uuid en Go ilustra algo más amplio sobre cómo maduran los lenguajes de programación. Go apostó históricamente por una stdlib minimalista y un ecosistema de terceros activo. Pero el ataque de typosquatting de diciembre de 2025 demostró que hay funcionalidades tan fundamentales —tan universalmente necesarias— que dejarlas en manos de dependencias externas crea riesgos sistémicos.
Para equipos que construyen en Go en LATAM y el mundo, esto tiene implicaciones concretas: menos ruido en auditorías de seguridad, menos incertidumbre en la gestión de dependencias, y acceso nativo a UUIDv7 para arquitecturas de bases de datos modernas. No es un cambio revolucionario, pero es exactamente el tipo de mejora silenciosa que hace que usar un lenguaje se sienta mejor con el tiempo.
Si estás planeando un proyecto nuevo en Go, vale la pena diseñar pensando en que crypto/uuid podría estar disponible en tu versión objetivo. Y si mantienes código existente con google/uuid, la migración, cuando llegue, debería ser trivial.
Fuentes
- Ecosistema Startup — UUID llega a la librería estándar de Go: qué cambia
- GitHub — Proposal: crypto/uuid: add API to generate and parse UUID (#62026)
- GitHub — Proposal paralela crypto/rand (#76319) — cerrada
- Socket Research — Paquetes Go maliciosos que imitan google/uuid (dic 2025)
- GitHub — google/uuid (referencia actual)
¿Estás migrando proyectos Go a UUIDv7? También te puede interesar: TypeScript 6.0 RC y el futuro de los compiladores en Go, cómo están cambiando los roles de ingeniería con la IA, y por qué el código IA puede parecer correcto pero no serlo.
