Em outras linguagens é muito comum variáveis serem inicializadas com undefined ou null.
Em Go toda variável já nasce com um valor. No qual é chamado de Zero Value.
Conceito
Em Go, declarar uma variável sem atribuir nada não é deixar ela "vazia". A linguagem coloca um valor padrão lá. Esse valor depende do tipo.
var x int
var s string
var b bool
fmt.Println(x, s, b) // 0 false
Nesse caso não temos lixo de memória, nem undefined ou null, temos um valor pré-definido.
Tabela rápida
Para consultar quando bater dúvida:
| Tipo | Zero value |
|---|---|
bool |
false |
inteiros (int, int64, uint...) |
0 |
floats (float32, float64) |
0.0 |
string |
"" |
ponteiros (*T) |
nil |
slices ([]T) |
nil |
maps (map[K]V) |
nil |
channels (chan T) |
nil |
| funções | nil |
| interfaces | nil |
arrays ([N]T) |
array com cada posição no zero value |
| structs | struct com cada campo no zero value |
Por que isso é bom
Segurança de memória
Em C, ler uma variável não inicializada devolve qualquer coisa que estava em memória naquele momento. Em Go isso não acontece. O compilador garante o valor inicial.
O famoso "useful zero value"
A biblioteca padrão é desenhada para que muitos tipos funcionem direto, sem precisar inicializar nada:
var b bytes.Buffer
b.WriteString("oi") // funciona
var mu sync.Mutex
mu.Lock() // funciona
var wg sync.WaitGroup
wg.Add(1) // funciona
Isso elimina uma porção de construtores que outras linguagens exigem.
Cuidados com tipos nil
Nem todo zero value é inofensivo. Slices, maps e channels têm nil como zero value, e cada um se comporta de um jeito quando usado nesse estado.
Slice nil
Slice nil aceita len, aceita range e aceita append. Por isso quase sempre dá para tratar igual a slice vazio:
var s []int
fmt.Println(len(s)) // 0
s = append(s, 1) // funciona, vira []int{1}
A diferença aparece se você comparar com nil:
var a []int
b := []int{}
fmt.Println(a == nil) // true
fmt.Println(b == nil) // false
Map nil
Aqui já muda de figura. Você pode ler de um map nil (volta o zero value do tipo do valor), mas escrever quebra o programa:
var m map[string]int
v := m["chave"] // ok, v == 0
m["chave"] = 1 // panic: assignment to entry in nil map
Antes de escrever em um map, sempre make:
m := make(map[string]int)
Channel nil
Channel nil bloqueia para sempre, tanto envio quanto recebimento. Parece bug, mas é útil dentro de select para desligar um case sob demanda.
Structs
Um struct também tem zero value. Cada campo recebe o zero value respectivo ao seu tipo.
type User struct {
Name string
Age int
Tags []string
}
var u User
// u.Name vale ""
// u.Age vale 0
// u.Tags vale nil
Se todos os campos forem comparáveis, dá para checar contra o zero value do tipo:
if u == (User{}) {
fmt.Println("usuário ainda não preenchido")
}
Composite literal: {} não é igual a nil
Isso é um pequeno detalhe que confunde no início:
var a []int // nil
b := []int{} // não é nil, é vazio
var m map[string]int // nil
n := map[string]int{} // não é nil, está pronto pra escrever
Os dois têm len igual a zero, mas o segundo já está alocado.
A confusão clássica em JSON
Aqui é onde zero values mais confunde quem está integrando APIs.
type T struct {
Name string
Age int
}
b, _ := json.Marshal(T{})
fmt.Println(string(b))
// {"Name":"","Age":0}
Atenção: json.Marshal retorna dois valores, []byte e error. Se você imprimir direto sem converter, vai aparecer um monte de número:
[123 34 78 97 109 101 ...] <nil>
Sempre string(b) ou fmt.Printf("%s\n", b).
A tag omitempty resolve em parte:
type T struct {
Name string `json:"name,omitempty"`
Age int `json:"age,omitempty"`
}
Mas aqui temos um problema. omitempty esconde qualquer zero value. Se Age for legitimamente 0, ou Active for legitimamente false, eles somem do JSON. Quem está do outro lado não sabe se o campo veio vazio ou se nunca foi enviado.
Como saber se o valor é zero de propósito
Esse é um problema comum em Go. Abaixo temos algumas alternativas.
1. Usar ponteiros
A solução mais comum em APIs REST é utilizar ponteiros, pois quando não inicializado, Go inicializa o campo com valor nil. Ponteiro com valor significa explícito, mesmo que o valor apontado seja zero.
type T struct {
Name *string `json:"name,omitempty"`
Age *int `json:"age,omitempty"`
Active *bool `json:"active,omitempty"`
}
2. omitzero (Go 1.24+)
Tag nova com semântica mais clara. Resolve dois pontos cegos do omitempty:
-
Struct zero some.
time.Time{}finalmente é tratado como vazio. -
Respeita
IsZero()em tipos próprios.
type T struct {
Name string `json:"name,omitzero"`
Age int `json:"age,omitzero"`
When time.Time `json:"when,omitzero"`
}
Para tipos próprios, basta implementar IsZero() bool:
type Money struct{ Cents int64 }
func (m Money) IsZero() bool { return m.Cents == 0 }
O que omitzero ainda NÃO resolve
omitzero continua sem distinguir zero explícito de zero por default em primitivos. Os dois são iguais em memória.
type T struct {
Age int `json:"age,omitzero"`
Active bool `json:"active,omitzero"`
}
// setando explicitamente:
t := T{Age: 0, Active: false}
b, _ := json.Marshal(t)
fmt.Println(string(b)) // {}
Mesmo escrevendo Age: 0 e Active: false na mão, o JSON sai vazio.
Podemos ter casos onde as propriedades podem ter valor false ou 0de forma proposital, podendo gerar um bug silencioso.
A saída é combinar com ponteiro:
type T struct {
Age *int `json:"age,omitzero"`
Active *bool `json:"active,omitzero"`
}
t := T{Age: ptr(0)}
// {"age":0} ← preserva zero explícito
t2 := T{}
// {} ← ausente de verdade
Se a diferença entre "ausente" e "zero explícito" importa pro consumidor da API, ponteiro é obrigatório, mesmo com omitzero.
Concluindo
Zero values são uma escolha de design que cabe bem com o estilo de Go: onde temos um comportamento previsível e com menos código de inicialização.
Devemos ter uma atenção redobrada quando estamos trabalhando com JSON onde campos podem ser omitidos, mesmo quando temos valores validos.
Top comments (0)