O receptor de um método é o valor sobre o qual ele opera, declarado antes do nome do método. Pode ser um receptor de valor (opera em uma cópia) ou um receptor de ponteiro (opera no original, pode modificá-lo). Escolher corretamente importa tanto para correção (mutação) quanto para desempenho.
Counter { count }
Increment() {
c.count++
}
c := Counter{}
c.Increment()
fmt.Println(c.count)
Um receptor de valor recebe uma cópia da struct, portanto modificações não afetam o original — útil para métodos somente leitura, mas um erro se você pretendeu mutar.
func (c *Counter) Increment() { // POINTER receiver — c points to the original
c.count++ // modifies the ACTUAL struct
}
c := Counter{}
c.Increment() // Go automatically takes &c
fmt.Println(c.count) // 1 — the original WAS modified
Um receptor de ponteiro opera na struct atual, então pode modificá-la. Go automaticamente pega o endereço (c.Increment() funciona mesmo em um valor).
Use a POINTER receiver when:
✓ The method needs to MODIFY the receiver (mutation)
✓ The struct is LARGE (avoid copying it on every call — performance)
✓ For CONSISTENCY (see below)
Use a VALUE receiver when:
✓ The method only READS, the type is small, and you want copy semantics
✓ The type is naturally a value (small structs, basic types)
// ✅ be consistent — if ANY method needs a pointer receiver, use pointer for ALL
func (c *Counter) Increment() { c.count++ }
func (c *Counter) Value() int { return c.count } // pointer too, for consistency
Misturar receptores de valor e de ponteiro em um tipo causa problemas sutis — a convenção é escolher um (geralmente ponteiro se algum método mutar) e usá-lo para todos os métodos.
type Incrementer interface { Increment() }
// if Increment has a POINTER receiver, only *Counter satisfies the interface, not Counter
var i Incrementer = &Counter{} // ✅ works
var j Incrementer = Counter{} // ❌ Counter (value) does NOT satisfy it
Esta é uma armadilha comum: com métodos de receptor de ponteiro, apenas o tipo de ponteiro satisfaz a interface.
A escolha entre receptor de valor e de ponteiro é uma decisão fundamental e frequentemente mal compreendida em Go que afeta correção, desempenho e satisfação de interface.
O bug mais comum é usar um receptor de valor quando você quis mutar — a modificação afeta silenciosamente apenas uma cópia, então a mudança "não persiste". Receptores de ponteiro são necessários para mutação e recomendados para structs grandes (para evitar cópias caras a cada chamada).
A regra de consistência (usar o mesmo tipo de receptor em todos os métodos de um tipo) evita confusão, e a sutileza de satisfação de interface (métodos de receptor de ponteiro significam que apenas o tipo de ponteiro satisfaz a interface) é uma armadilha clássica que causa erros "does not implement interface".
Compreender estes conceitos é essencial para escrever Go correto e eficiente e está entre os tópicos mais comuns práticos e de entrevista, já que a escolha tem consequências não-óbvias.