A method's receiver is the value it operates on, declared before the method name. It can be a value receiver (operates on a copy) or a pointer receiver (operates on the original, can modify it). Choosing correctly matters for both correctness (mutation) and performance.
Counter { count }
Increment() {
c.count++
}
c := Counter{}
c.Increment()
fmt.Println(c.count)
A value receiver gets a copy of the struct, so modifications don't affect the original — useful for read-only methods, but a bug if you intended to mutate.
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
A pointer receiver operates on the actual struct, so it can modify it. Go auto-takes the address (c.Increment() works even on a value).
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
Mixing value and pointer receivers on one type causes subtle issues — convention is to pick one (usually pointer if any method mutates) and use it for all methods.
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
This is a common gotcha: with pointer-receiver methods, only the pointer type satisfies the interface.
The value-vs-pointer receiver choice is a fundamental, frequently-misunderstood Go decision that affects correctness, performance, and interface satisfaction.
The most common bug is using a value receiver when you meant to mutate — the modification silently affects only a copy, so the change "doesn't stick." Pointer receivers are required for mutation and recommended for large structs (to avoid expensive copies on every call).
The consistency rule (use the same receiver type across a type's methods) avoids confusion, and the interface-satisfaction subtlety (pointer-receiver methods mean only the pointer type satisfies the interface) is a classic gotcha that causes "does not implement interface" errors.
Understanding these is essential for writing correct, efficient Go and is among the most common practical and interview topics, since the choice has non-obvious consequences.