La Biblioteca Estándar de Go: Baterías Incluidas
La biblioteca estándar de Go no es una ocurrencia tardía.
//
Busca en todas las páginas de la documentación
La biblioteca estándar de Go no es una ocurrencia tardía.
Es el conjunto de herramientas predeterminado para HTTP, JSON, criptografía, pruebas, concurrencia y la mayoría del trabajo de sistemas cotidianos.
Conceptos Básicos de la Biblioteca Estándar recopila fragmentos ejecutables; los artículos hermanos profundizan en paquetes de I/O, tiempo, criptografía, registro, perfilado y redes.
Cada instalación de Go incluye el mismo árbol de biblioteca estándar bajo GOROOT.
Importas paquetes por ruta (import "net/http") sin añadir un requisito de go.mod para el código de la biblioteca estándar.
La filosofía de diseño favorece paquetes pequeños y ortogonales sobre mega-frameworks.
io define interfaces de lector y escritor; bufio añade buffering; os abre archivos; net/http sirve HTTP.
Cada capa hace un trabajo y se compone con la siguiente.
La promesa de compatibilidad de Go 1 significa que las APIs de la biblioteca estándar rara vez rompen programas existentes.
Las nuevas características llegan como nuevas funciones, nuevos tipos o nuevos subpaquetes (math/rand/v2, log/slog) en lugar de cambios semánticos silenciosos.
Esa estabilidad es la razón por la que el código Go de producción a menudo se ejecuta durante años con HTTP de la biblioteca estándar y database/sql sin perseguir versiones principales de frameworks.
La cultura comunitaria refuerza el valor predeterminado: recurre primero a la biblioteca estándar, añade una dependencia solo cuando la biblioteca estándar carezca claramente de la capacidad que necesitas.
Los paquetes de la biblioteca estándar interactúan a través de interfaces y contexto, no de herencia.
http.Handler es un método.
io.Reader y io.Writer son dos métodos.
Middleware, buffering, compresión y encriptación son envoltorios alrededor de esas interfaces.
código de la aplicación
|
v
net/http / database/sql / encoding/json
|
v
os / io / bufio / crypto / context
|
v
runtime / syscall (plataforma)
Las bibliotecas de terceros generalmente se sientan al lado de la biblioteca estándar, no la reemplazan.
Enrutadores como chi, gin y echo todavía exportan http.Handler.
Registradores como zap y zerolog complementan log/slog.
Los ORM envuelven database/sql.
Elegir código externo es un compromiso: mayor velocidad de desarrollo de características frente a otro módulo para auditar, fijar y actualizar.
| Señal | Mantente en la biblioteca estándar | Alcanza externamente |
|---|---|---|
| API HTTP con enrutamiento y JSON | net/http + encoding/json | Frameworks de enlace/validación enriquecidos |
| Registros estructurados | log/slog (Go 1.21+) | Ecosistemas heredados ya en zap/zerolog |
| IDs aleatorios | crypto/rand | N/A para bytes sensibles a la seguridad |
| Acceso SQL | database/sql + driver | ORM pesado con migraciones y relaciones |
| Archivos de configuración | os.Getenv, flag, embed | Configuración multifuente estilo viper |
La deprecación es gradual.
Las funciones globales de math/rand permanecen, pero math/rand/v2 ofrece una API más limpia.
El paquete log todavía funciona, pero log/slog es la ruta de registro estructurado para código nuevo.
La biblioteca estándar enseña la migración en lugar de la eliminación abrupta.
Las grandes organizaciones se benefician de plantillas que priorizan la biblioteca estándar: valores predeterminados de tiempo de espera compartidos para http.Server, manejadores JSON de slog y configuraciones de pool de database/sql integradas en iniciadores internos.
La revisión de seguridad escala mejor cuando cada servicio no importa una pila HTTP diferente.
Los ganchos de observabilidad (runtime/pprof, net/http/pprof, expvar) se incluyen en el árbol para que el perfilado no requiera agentes específicos del proveedor.
Los objetivos embebidos y WASM (tinygo, hosts wazero) pueden tener una disponibilidad limitada de la biblioteca estándar; conoce tu objetivo de compilación antes de asumir que net/http o database/sql se enlazan.
| Enfoque | Fortaleza | Debilidad | Mejor Ajuste |
|---|---|---|---|
| Servicio solo con biblioteca estándar | Dependencias mínimas, actualizaciones uniformes | Más código repetitivo para características avanzadas | APIs internas, sidecars, CLIs |
| Biblioteca estándar + bibliotecas enfocadas | Llena brechas específicas (enrutador, validador) | Gráfico de dependencias moderado | Equipos de producto con niveles de habilidad mixtos |
| Pila pesada de frameworks | Rápido andamiaje | Gráfico transitivo grande, dependencia del framework | Aplicaciones Greenfield con experiencia en frameworks |
Los proyectos Greenfield de Go 1.26 deberían usar por defecto slog, math/rand/v2 y los patrones de enrutamiento de net/http de Go 1.22+ mientras mantienen las importaciones de terceros justificadas en ADRs o READMEs de módulos.
log está obsoleto" - log es registro de estilo legado; todavía funciona, pero log/slog es la ruta estructurada para código nuevo.net/http es suficiente para la mayoría de las pasarelas REST y RPC cuando se combina con convenciones claras de middleware.Significa que las tareas comunes del sistema (HTTP, JSON, primitivas TLS, pruebas, I/O de archivos, tiempo, sincronización) se incluyen con la instalación del compilador.
No necesitas instalar una plataforma estándar separada con npm.
El código de terceros llena las brechas, no la base.
No.
Las importaciones como "fmt" y "net/http" se resuelven desde GOROOT automáticamente.
go.mod registra las dependencias de módulos para el código fuera de la biblioteca estándar.
Cuando la biblioteca estándar carece de la capacidad (DSLs de validación avanzados, gráficos de relaciones ORM, SDKs específicos del proveedor) o cuando los estándares organizacionales exigen una biblioteca compartida.
Documenta la brecha en un ADR o en la justificación del README.
La promesa de compatibilidad de Go 1 evita romper programas válidos existentes.
El nuevo comportamiento llega en nuevos identificadores o paquetes; las APIs obsoletas persisten con guías de migración.
No.
Proporciona bloques de construcción de servidor, cliente, enrutamiento y TLS.
Los frameworks añaden opiniones de enlace, validación y diseño de proyectos sobre http.Handler.
Usa log/slog para registro estructurado y por niveles en nuevos servicios.
Mantén log solo cuando mantengas código heredado o scripts pequeños donde la estructura no sea necesaria.
database/sql define la interfaz; los drivers (pgx, mysql, sqlite) son módulos separados.
La división mantiene los protocolos de proveedores actualizables sin atarlos al ciclo de lanzamiento de Go.
Los paquetes pequeños se componen a través de interfaces y evitan forzar una abstracción para cada caso de uso.
Ensamblas capas HTTP, JSON y SQL explícitamente en lugar de heredar un mega-framework.
No es necesario.
La biblioteca estándar siempre está presente con la cadena de herramientas.
Haz "vendor" de módulos de terceros cuando necesites compilaciones reproducibles sin conexión de dependencias externas.
Comienza en pkg.go.dev/std, busca por tarea ("json", "tls", "template") y lee la documentación de los paquetes, además de los artículos hermanos en esta sección.
A menudo lo contrario para los desarrolladores de Go: menos opciones, APIs predecibles y ejemplos de copiar y pegar de la documentación aceleran los primeros despliegues.
Los frameworks ayudan cuando necesitas su ergonomía específica.
Los módulos versionan el código externo.
La versión de la biblioteca estándar sigue tu cadena de herramientas de Go (por ejemplo, Go 1.26.x).
Actualizar Go actualiza las correcciones y características de la biblioteca estándar juntas.
Versiones de la Pila: Esta página fue escrita para Go 1.26.x (predeterminado Green Tea GC, go fix modernizadores - verificar parche en la compilación), chi (última versión - verificar en la compilación), gin (última versión - verificar en la compilación), echo (última versión - verificar en la compilación), google.golang.org/grpc (última versión - verificar en la compilación), sigs.k8s.io/controller-runtime (última versión - verificar en la compilación), kubebuilder (última versión - verificar en la compilación), tinygo (última versión - verificar objetivos de placa en la compilación), wazero (última versión - verificar en la compilación) y golangci-lint (última versión - verificar conjunto de linters en la compilación).
Revisado por Chris St. John·Última actualización: 19 jul 2026