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:

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:

1. Struct zero some. time.Time{} finalmente é tratado como vazio.
2. 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.

Referências

• Effective Go: The zero value
• Go Spec: The zero value