El receptor de un método es el valor sobre el que opera, declarado antes del nombre del método. Puede ser un receptor de valor (opera sobre una copia) o un receptor de puntero (opera sobre el original, puede modificarlo). Elegir correctamente importa tanto para la corrección (mutación) como para el rendimiento.
Counter { count }
Increment() {
c.count++
}
c := Counter{}
c.Increment()
fmt.Println(c.count)
Un receptor de valor obtiene una copia de la estructura, por lo que las modificaciones no afectan al original — útil para métodos de solo lectura, pero es un error si pretendías 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
Un receptor de puntero opera sobre la estructura actual, por lo que puede modificarla. Go toma automáticamente la dirección (c.Increment() funciona incluso en un 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
Mezclar receptores de valor y puntero en un tipo causa problemas sutiles — la convención es elegir uno (generalmente puntero si algún método muta) y usarlo para todos los 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 es una trampa común: con métodos receptores de puntero, solo el tipo de puntero satisface la interfaz.
La elección del receptor de valor versus puntero es una decisión fundamental de Go que se entiende frecuentemente mal y que afecta la corrección, el rendimiento y la satisfacción de la interfaz.
El error más común es usar un receptor de valor cuando pretendías mutar — la modificación afecta silenciosamente solo una copia, por lo que el cambio "no se mantiene". Los receptores de puntero son obligatorios para mutación y se recomiendan para estructuras grandes (para evitar copias costosas en cada llamada).
La regla de consistencia (usar el mismo tipo de receptor en los métodos de un tipo) evita confusión, y la sutileza de satisfacción de interfaz (los métodos receptores de puntero significan que solo el tipo de puntero satisface la interfaz) es una trampa clásica que causa errores "no implementa interfaz".
Comprender estos conceptos es esencial para escribir Go correcto y eficiente, y está entre los temas más comunes en la práctica e entrevistas, ya que la elección tiene consecuencias no obvias.