A Biblioteca Padrão do Go: Pilhas Incluídas
A biblioteca padrão do Go não é uma reflexão tardia.
//
Busque em todas as páginas da documentação
A biblioteca padrão do Go não é uma reflexão tardia.
É o conjunto de ferramentas padrão para HTTP, JSON, criptografia, testes, concorrência e a maioria dos trabalhos de sistemas do dia a dia.
Noções Básicas da Biblioteca Padrão coleta trechos executáveis; artigos irmãos aprofundam pacotes de I/O, tempo, criptografia, logging, profiling e rede.
Cada instalação do Go inclui a mesma árvore de biblioteca padrão sob GOROOT.
Você importa pacotes por caminho (import "net/http") sem adicionar um requisito go.mod para código da biblioteca padrão.
A filosofia de design favorece pacotes pequenos e ortogonais em vez de mega-frameworks.
io define interfaces de leitor e gravador; bufio adiciona buffering; os abre arquivos; net/http serve HTTP.
Cada camada faz um trabalho e se compõe com a próxima.
A promessa de compatibilidade Go 1 significa que as APIs da biblioteca padrão raramente quebram programas existentes.
Novos recursos chegam como novas funções, novos tipos ou novos subpacotes (math/rand/v2, log/slog) em vez de alterações semânticas silenciosas.
Essa estabilidade é o motivo pelo qual o código Go de produção muitas vezes roda por anos com HTTP da biblioteca padrão e database/sql sem perseguir versões principais de frameworks.
A cultura da comunidade reforça o padrão: use a biblioteca padrão primeiro, adicione uma dependência apenas quando a biblioteca padrão claramente não tiver a capacidade que você precisa.
Pacotes da biblioteca padrão interagem através de interfaces e contexto, não herança.
http.Handler é um método.
io.Reader e io.Writer são dois métodos.
Middleware, buffering, compressão e criptografia são wrappers em torno dessas interfaces.
código da aplicação
|
v
net/http / database/sql / encoding/json
|
v
os / io / bufio / crypto / context
|
v
runtime / syscall (plataforma)
Bibliotecas de terceiros geralmente ficam ao lado da biblioteca padrão, não a substituindo.
Roteadores como chi, gin e echo ainda exportam http.Handler.
Loggers como zap e zerolog complementam log/slog.
ORMs envolvem database/sql.
Escolher código externo é um compromisso: velocidade de desenvolvimento de recursos versus outro módulo para auditar, fixar e atualizar.
| Sinal | Fique na biblioteca padrão | Alcance externamente |
|---|---|---|
| API HTTP com roteamento e JSON | net/http + encoding/json | Frameworks ricos em binding/validação |
| Logs estruturados | log/slog (Go 1.21+) | Ecossistemas legados já em zap/zerolog |
| IDs aleatórios | crypto/rand | N/A para bytes sensíveis à segurança |
| Acesso SQL | database/sql + driver | ORM pesado com migrações e relações |
| Arquivos de configuração | os.Getenv, flag, embed | Configuração multi-fonte estilo viper |
A depreciação é gradual.
Funções globais de math/rand permanecem, mas math/rand/v2 oferece uma API mais limpa.
O pacote log ainda funciona, mas log/slog é o caminho de logging estruturado para o futuro.
A biblioteca padrão ensina migração em vez de remoção abrupta.
Grandes organizações se beneficiam de modelos de preferência pela biblioteca padrão: padrões de tempo limite de http.Server compartilhados, manipuladores JSON de slog e configurações de pool de database/sql incorporadas em starters internos.
A revisão de segurança escala melhor quando cada serviço não importa uma pilha HTTP diferente.
Ganchos de observabilidade (runtime/pprof, net/http/pprof, expvar) são enviados na árvore, então o profiling não requer agentes específicos do fornecedor.
Alvos embarcados e WASM (tinygo, hosts wazero) podem subsetizar a disponibilidade da biblioteca padrão; conheça seu alvo de compilação antes de assumir que net/http ou database/sql se vinculam.
| Abordagem | Força | Fraqueza | Melhor Ajuste |
|---|---|---|---|
| Serviço apenas com biblioteca padrão | Dependências mínimas, atualizações uniformes | Mais boilerplate para recursos avançados | APIs internas, sidecars, CLIs |
| Biblioteca padrão + bibliotecas focadas | Preenche lacunas específicas (roteador, validador) | Gráfico de dependência moderado | Equipes de produto com níveis de habilidade mistos |
| Pilha pesada de framework | Rápido scaffolding | Grande gráfico transitivo, dependência de framework | Aplicações Greenfield com expertise em framework |
Projetos Greenfield Go 1.26 devem usar slog, math/rand/v2 e padrões de roteamento net/http do Go 1.22+ por padrão, mantendo importações de terceiros justificadas em ADRs ou READMEs de módulos.
log é logging estilo legado; ainda funciona, mas log/slog é o caminho estruturado para novo código.net/http é suficiente para a maioria dos gateways REST e RPC quando combinado com convenções claras de middleware.Significa que tarefas comuns de sistemas (HTTP, JSON, primitivas TLS, testes, I/O de arquivos, tempo, sincronização) vêm com a instalação do compilador.
Você não instala uma plataforma padrão separada com npm.
Código de terceiros preenche lacunas, não a base.
Não.
Importações como "fmt" e "net/http" são resolvidas a partir do GOROOT automaticamente.
go.mod registra dependências de módulos para código fora da biblioteca padrão.
Quando a biblioteca padrão não tem a capacidade (DSLs de validação avançada, grafos de relação ORM, SDKs específicos de fornecedor) ou quando os padrões organizacionais exigem uma biblioteca compartilhada.
Documente a lacuna em um ADR ou em um README de justificativa.
A promessa de compatibilidade Go 1 evita quebrar programas válidos existentes.
Novos comportamentos chegam em novos identificadores ou pacotes; APIs obsoletas persistem com guias de migração.
Não.
Ele fornece blocos de construção de servidor, cliente, roteamento e TLS.
Frameworks adicionam opiniões de binding, validação e layout de projeto sobre http.Handler.
Use log/slog para logging estruturado e com níveis em novos serviços.
Mantenha log apenas ao manter código legado ou scripts minúsculos onde a estrutura é desnecessária.
database/sql define a interface; drivers (pgx, mysql, sqlite) são módulos separados.
A divisão mantém os protocolos de fornecedor atualizáveis sem vinculá-los ao cronograma de lançamento do Go.
Pacotes pequenos se compõem através de interfaces e evitam forçar uma abstração para todos os casos de uso.
Você monta camadas HTTP, JSON e SQL explicitamente em vez de herdar um mega-framework.
Não há necessidade.
A biblioteca padrão está sempre presente com o toolchain.
Faça o versionamento de módulos de terceiros quando precisar de compilações offline reproduzíveis de dependências externas.
Comece em pkg.go.dev/std, pesquise por tarefa ("json", "tls", "template") e leia a documentação dos pacotes, além dos artigos irmãos nesta seção.
Frequentemente o oposto para desenvolvedores Go: menos escolhas, APIs previsíveis e exemplos de copiar e colar da documentação aceleram as primeiras implantações.
Frameworks ajudam quando você precisa de sua ergonomia específica.
Módulos versionam código externo.
A versão da biblioteca padrão acompanha seu toolchain Go (por exemplo, Go 1.26.x).
Atualizar o Go atualiza correções e recursos da biblioteca padrão juntos.
Versões de Pilha: Esta página foi escrita para Go 1.26.x (padrão Green Tea GC, go fix modernizadores - verifique o patch na compilação), chi (mais recente - verifique na compilação), gin (mais recente - verifique na compilação), echo (mais recente - verifique na compilação), google.golang.org/grpc (mais recente - verifique na compilação), sigs.k8s.io/controller-runtime (mais recente - verifique na compilação), kubebuilder (mais recente - verifique na compilação), tinygo (mais recente - verifique os alvos de placa na compilação), wazero (mais recente - verifique na compilação) e golangci-lint (mais recente - verifique o conjunto de linters na compilação).
Revisado por Chris St. John·Última atualização: 19 de jul. de 2026