คุณกำลังแก้ของจริง หรือแก้ copy?

1 · กฎข้อเดียวที่ต้องจำ

ก่อนอื่น — * กับ & อ่านยังไง

ตัวแปรทุกตัวใน Go นั่งอยู่ที่ "ช่องหนึ่งในหน่วยความจำ" และช่องนั้นมีเลขที่อยู่ของมันเอง เหมือนบ้านมีเลขที่ pointer คือตัวแปรที่เก็บ "เลขที่บ้าน" ของตัวแปรอีกตัว ไม่ได้เก็บตัวของมันเอง

สังเกตว่า * มีสองหน้าที่คนละเรื่องกัน วิธีแยกคือ ถ้า * ติดอยู่กับชื่อชนิด = ประกาศชนิด · ถ้าติดอยู่กับชื่อตัวแปร = เดินตามที่อยู่ไป

func tryValue(n int)  { n = 999 }
func tryPtr(n *int)   { *n = 999 }

x := 42
tryValue(x)   // x ยังเป็น 42  — แก้ copy ของเลข
tryPtr(&x)    // x เป็น 999    — แก้ผ่านที่อยู่

ตัว tryPtr ก็ได้ copy ของ pointer มาเหมือนกัน — แต่ copy ของ ที่อยู่บ้าน ก็ยังชี้ไปบ้านหลังเดิม เลยเข้าไปแก้ของในบ้านได้

2 · จุดที่กฎนี้เล่นงานคุณ #1: for range

type User struct{ Name string; Age int }

users := []User{{"Alice", 30}, {"Bob", 25}}

for _, u := range users {
    u.Name = "CHANGED"
}

fmt.Println(users[0].Name)

for i := range users {
    users[i].Name = "CHANGED"   // ✓ เข้าถึงช่องจริงใน slice
}

3 · จุดที่กฎนี้เล่นงานคุณ #2: struct ใน map

type Product struct{ Name string; Qty int }

inv := map[string]Product{
    "SKU-1": {Name: "Mouse", Qty: 50},
}

inv["SKU-1"].Qty = 49

ทางออก 3 แบบ เรียงตามที่ใช้จริงบ่อยที่สุด:

// สมมติว่า Product เพิ่ม field Tags เข้ามาแล้ว:
//   type Product struct{ Name string; Qty int; Tags []string }

// 1) เก็บเป็น pointer ตั้งแต่แรก — ใช้บ่อยสุดในงานจริง
inv := map[string]*Product{"SKU-1": {Name: "Mouse", Qty: 50}}
inv["SKU-1"].Qty = 49          // ✓ ได้

// 2) อ่านออกมา แก้ แล้วยัดกลับทั้งก้อน
p := inv["SKU-1"]
p.Qty = 49
inv["SKU-1"] = p               // ✓ ได้

// 3) field ที่เป็น slice แก้ได้เลย แม้ map value จะเป็น non-addressable
//    (ตรงนี้กลับมาใช้ map แบบไม่ pointer เพื่อให้เห็นประเด็นชัด ๆ)
inv2 := map[string]Product{"SKU-1": {Name: "Mouse", Qty: 50, Tags: []string{"old"}}}
inv2["SKU-1"].Tags[0] = "new"  // ✓ ได้
inv2["SKU-1"].Qty = 49         // ✗ ยังไม่ได้ — compile error เหมือนเดิม

ข้อ 3 ดูขัดกับที่เพิ่งบอกไป แต่ไม่ขัดเลย เพราะ Tags เป็น slice ซึ่งตัวมันเองก็เป็นแค่ header (ป้ายสรุปเล็ก ๆ ที่จดไว้ว่าของจริงกองอยู่ที่ไหน ยาวเท่าไหร่) ที่ชี้ไป array ก้อนหนึ่ง (บทที่ 06) Tags[0] จึงไม่ได้แตะตัว map เลย แต่แตะ array ที่อยู่นอก map ต่างหาก — และช่องใน array นั้นมีที่อยู่คงที่ เลย addressable

4 · จุดที่กฎนี้เล่นงานคุณ #3: receiver ของ method

Method ก็คือฟังก์ชันที่มี parameter พิเศษข้างหน้าชื่อ receiver

ต่างจากฟังก์ชันธรรมดาตรงวงเล็บชุดแรกก่อนชื่อเท่านั้น — วงเล็บชุดนั้นเรียกว่า receiver และมันคือตัวบอกว่า method นี้ "ห้อยอยู่กับ" ชนิดไหน เวลาเรียกจึงเขียนเป็น acc.Deposit(500)

type Account struct{ Balance float64 }

func (a Account)  Show() float64      { return a.Balance }
func (a *Account) Deposit(x float64) { a.Balance += x }

acc := Account{Balance: 1000}
acc.Deposit(500)              // Go แปลงให้เป็น (&acc).Deposit(500)
fmt.Println(acc.Show())      // 1500

เกณฑ์ตัดสินจาก Go Code Review Comments

นี่คือเกณฑ์ที่ reviewer จริงใช้ตัดสิน — ย่อจาก Go Code Review Comments · Receiver Type:

• ถ้า method ต้องแก้ค่า receiver → ต้องเป็น pointer (บังคับ)
• ถ้า receiver เป็น struct ใหญ่ หรือ array ใหญ่ → pointer มีประสิทธิภาพกว่า ("How large is large? Assume it's equivalent to passing all its elements as arguments")
• ถ้า receiver มี sync.Mutex อยู่ข้างใน → ต้องเป็น pointer ไม่งั้น copy แล้ว lock ไม่ทำงาน (sync.Mutex = ตัวล็อกที่กันไม่ให้งานหลายชิ้นแก้ของก้อนเดียวกันพร้อมกัน · พอ copy ไปก็กลายเป็นล็อกคนละดอก เลยไม่ได้กันอะไรเลย)
• ถ้า receiver เป็น map, func, channel → ไม่ต้องใช้ pointer เพราะสามชนิดนี้ตัวมันเองเป็นแค่ header เล็ก ๆ ที่ชี้ไปโครงสร้างจริงข้างหลังอยู่แล้ว (แบบเดียวกับ slice header ในบทที่ 06) ก็อปมันไปก็ยังแตะของจริงก้อนเดิมได้ ใส่ * เพิ่มก็ได้แค่ความยุ่งยากในการเขียน
• ถ้าเป็น slice ก็เหตุผลเดียวกัน — ยกเว้นเมื่อ method นั้นต้อง append หรือเปลี่ยนความยาวของ slice เอง เพราะสองอย่างนั้นแก้ที่ตัว header (Len/Cap/Data) ซึ่งเป็นของที่ก็อปมา → ต้องใช้ pointer receiver ถึงจะมีผลข้างนอก
• ถ้าเป็น struct เล็ก ไม่มี field ที่ต้องแก้ และเป็น value โดยธรรมชาติ (แบบ time.Time) → value receiver เหมาะกว่า
• "Don't mix receiver types" — type เดียวกันเลือกแบบเดียวทั้งหมด
• "When in doubt, use a pointer receiver."

5 · ทดสอบความจำ

6 · ลงมือทำ

อ่านต่อจากต้นทาง

แหล่งหลักที่แนะนำ: Go Code Review Comments — หัวข้อ Receiver Type เป็นเกณฑ์ที่ทีม Go ใช้ review จริง ยาวไม่ถึงหน้าเดียว ควรอ่านให้จบทั้งหน้าเลยเพราะหัวข้ออื่น (Indent Error Flow, Don't Panic) จะเจอในคอร์สวันถัด ๆ ไปแน่นอน

อ้างอิง

• Go Code Review Comments — Receiver Type — เกณฑ์เลือก value vs pointer receiver
• The mechanics of 'append' — "even though a slice contains a pointer, it is itself a value"
• Go spec — Address operators — นิยามของ addressable