Gin — router ที่อ่านออก และ Context ที่ทำงานแทน

1 · Gin ไม่ได้มาแทน net/http — มันมานั่งทับ

ความเข้าใจผิดข้อแรกของทุกคนคือคิดว่า Gin เป็น "web server คนละตัว" กับที่เรียนมาในบท 37
ไม่ใช่ครับ — Gin ยังใช้ net/http เป็นคนรับ TCP และ parse HTTP อยู่เหมือนเดิมทุกตัวอักษร
(TCP = ท่อรับส่งข้อมูลดิบระหว่างสองเครื่อง · parse HTTP = แกะข้อความที่ไหลมาในท่อ ให้กลายเป็น method / path / header ที่โค้ดหยิบไปใช้ได้)
*gin.Engine เป็นแค่ http.Handler ตัวหนึ่ง (มี method ServeHTTP) ที่คุณเอาไปเสียบแทน *http.ServeMux ได้ตรง ๆ

ผมพิสูจน์ข้อนี้ตลอดทั้งบทโดยไม่รู้ตัว — โค้ดที่ผมใช้ยิงทดสอบทุกอันเขียนแบบนี้:

ts := httptest.NewServer(r)   // r คือ *gin.Engine — httptest รับ http.Handler เท่านั้น

httptest.NewServer รับพารามิเตอร์เป็น http.Handler ถ้า *gin.Engine ไม่ใช่ http.Handler บรรทัดนี้จะคอมไพล์ไม่ผ่าน แต่มันผ่าน และ server ทำงานได้ — นี่คือ interface กับ duck typing (มีเมธอดครบตามที่ interface ขอ ก็นับว่าใช้แทนกันได้เลย ไม่ต้องไปประกาศว่า "ฉันเป็นชนิดนี้นะ") จาก บทเรียน 10 ทำงานให้เห็นของจริง

  request จาก browser
      │
      ▼
  net/http            ← รับ TCP, parse HTTP, จัดการ goroutine ต่อ connection
      │                  (ตัวนี้ไม่หายไปไหน แม้ใช้ Gin)
      ▼
  http.Handler        ← ช่องเสียบเดียว: เสียบ ServeMux ก็ได้ เสียบ gin.Engine ก็ได้
      │
      ├─▶ *http.ServeMux   → handler(w http.ResponseWriter, r *http.Request)
      │
      └─▶ *gin.Engine      → handler(c *gin.Context)
                              (c ห่อ w กับ r ไว้ข้างในอีกที)

สิ่งที่ Gin เพิ่มเข้ามาจริง ๆ มีสองอย่างเท่านั้น:

1. router ที่เร็วกว่าและเขียน param ได้สั้นกว่า — ข้างในเป็น radix tree (ต้นไม้ที่เก็บ path โดยรวบส่วนที่ขึ้นต้นเหมือนกันไว้กิ่งเดียว เช่น /users/me กับ /users/:id ใช้กิ่ง /users/ ร่วมกัน — หา route เจอโดยไม่ต้องไล่เทียบทีละเส้น) ที่ยกมาจาก httprouter (ไฟล์ tree.go ใน Gin ยังติด license header ของ httprouter อยู่เลย)
2. *gin.Context — ตัวห่อ w กับ r พร้อมเมธอดสำเร็จรูปที่คุณเคยเขียนเองในบท 37 (c.Param, c.Query, c.JSON)

2 · เขียน Gin ตัวแรก — แล้วอ่าน log ที่มันพ่นออกมาให้ออก

package main

import (
    "net/http"

    "github.com/gin-gonic/gin"
)

func main() {
    r := gin.Default()

    r.GET("/ping", func(c *gin.Context) {
        c.JSON(http.StatusOK, gin.H{"message": "pong"})
    })

    r.Run(":8080")
}

ก่อนอ่านตาราง — สองคำนี้จะโผล่ทั้งบท ขอนิยามให้ชัดก่อน

• engine คือ *gin.Engine — ตัวที่เก็บตาราง route ทั้งหมดไว้ เทียบตรง ๆ กับ *http.ServeMux ของบท 37
• middleware คือฟังก์ชันที่ถูกเรียกก่อน (และหลัง) handler ของเรา ทุก request เช่นตัวที่คอยพิมพ์ log หรือคอยดัก panic — เขียนหน้าตาเหมือน handler เป๊ะ (func(c *gin.Context)) ต่างกันแค่ว่ามันไม่ได้เป็นคนตอบ แต่เป็นคนที่ยืนขวางทางอยู่

ห้าชิ้นในโค้ดนี้ ต้องแยกให้ออกว่าอันไหนคืออะไร:

log ตอน boot ที่คนใหม่ตกใจ

พอรัน gin.Default() ในโหมด default มันพ่นก้อนนี้ออกมาก่อนรับ request สักตัว
(ก้อนนี้มาจากโปรแกรมทดสอบของผม ซึ่งลง route ไว้สองเส้นคือ /ping กับ /boom และฟังพอร์ต :18081 — ถ้าคุณรันโค้ดข้างบนตรง ๆ จะเห็นแค่บรรทัด /ping และท้ายสุดเป็น :8080 ที่เหลืออกมาเหมือนกันทุกบรรทัด)

[GIN-debug] [WARNING] Creating an Engine instance with the Logger and Recovery middleware already attached.

[GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
 - using env:	export GIN_MODE=release
 - using code:	gin.SetMode(gin.ReleaseMode)

[GIN-debug] GET    /ping                     --> main.main.func1 (3 handlers)
[GIN-debug] GET    /boom                     --> main.main.func2 (3 handlers)
[GIN-debug] [WARNING] You trusted all proxies, this is NOT safe. We recommend you to set a value.
Please check https://github.com/gin-gonic/gin/blob/master/docs/doc.md#dont-trust-all-proxies for details.
[GIN-debug] Listening and serving HTTP on :18081

อ่านให้ออกทีละบรรทัด — ไม่มีบรรทัดไหนคือ error สักบรรทัด

• [GIN-debug] GET /ping --> main.main.func1 คือตาราง route ที่ลงทะเบียนสำเร็จ ใช้ตรวจว่าพิมพ์ path ตกหรือเปล่าได้ดีมาก
• (3 handlers) ไม่ได้แปลว่ามี 3 route — แปลว่า request ที่เข้า path นี้จะวิ่งผ่านฟังก์ชัน 3 ตัว คือ Logger + Recovery + handler ของเรา (เดี๋ยวหัวข้อ 3 พิสูจน์ตัวเลขนี้)
• บรรทัด trusted all proxies โผล่ตอน r.Run() เท่านั้น
  reverse proxy คือเครื่องที่ยืนอยู่หน้าเซิร์ฟเวอร์เรา (เช่น nginx, load balancer) รับ request จาก browser แล้วส่งต่อมาให้เราอีกที — พอเป็นแบบนั้น IP ที่เราเห็นจะเป็นของ proxy ไม่ใช่ของผู้ใช้จริง proxy เลยแปะ IP จริงมาให้ใน header ชื่อ X-Forwarded-For
  ที่ Gin เตือนคือ: มันจะเชื่อ header ตัวนั้นจากใครก็ได้ แปลว่าใครยิงตรงเข้ามาก็ปลอม IP ตัวเองได้ — ยังไม่ต้องแก้ตอนเรียน แต่ต้องรู้ว่าบรรทัดนี้ไม่ใช่ error

และเมื่อมี request เข้ามา Logger จะพ่นบรรทัดนี้ต่อ 1 request:

[GIN] 2026/08/20 - 21:49:10 | 200 |  87.25µs |       127.0.0.1 | GET      "/ping"

3 · gin.Default() vs gin.New() — ต่างกันสองบรรทัด แต่ต่างกันคนละโลก

ทุกคนพิมพ์ gin.Default() ตามตัวอย่าง โดยไม่เคยรู้ว่ามันแถมอะไรมาให้บ้าง ผมเลยเปิดฝาดูด้วยการนับ Handlers แล้วพิมพ์ชื่อฟังก์ชันจริงออกมา
(./p1 คือชื่อโฟลเดอร์โปรแกรมทดสอบของผมเอง ไม่ใช่คำสั่งมาตรฐานอะไร — ของคุณจะชื่ออะไรก็ได้ ถ้าโค้ดอยู่ในโฟลเดอร์ปัจจุบันก็สั่ง go run . เฉย ๆ)

$ go run ./p1
len(Default().Handlers) = 2
len(New().Handlers)     = 0
Default handler[0] = github.com/gin-gonic/gin.LoggerWithConfig.func1
Default handler[1] = github.com/gin-gonic/gin.CustomRecoveryWithWriter.func1

จบ — Default() = New() + Logger + Recovery เป๊ะ ๆ ไม่มีอย่างอื่นแถม
นี่ยังอธิบาย (3 handlers) เมื่อกี้ด้วย: 2 ตัวนี้ + handler ของเรา = 3
ถ้าสร้างด้วย gin.New() route เดียวกันจะขึ้น (1 handlers)

d := gin.Default()                                    // ฟังอยู่ที่ :18081
d.GET("/boom", func(c *gin.Context) { panic("explode") })

n := gin.New()                                        // ฟังอยู่ที่ :18082
n.GET("/boom", func(c *gin.Context) { panic("explode") })

$ curl -s -o /dev/null -w "status=%{http_code}\n" http://127.0.0.1:18081/boom   # gin.Default()
status=500

$ curl -s -o /dev/null -w "status=%{http_code}\n" http://127.0.0.1:18082/boom   # gin.New()
FAILED: curl status=000

2026/08/20 21:49:10 [Recovery] 2026/08/20 - 21:49:10 panic recovered:
GET /boom HTTP/1.1
Host: 127.0.0.1:18081
Accept: */*
User-Agent: curl/8.13.0

explode
.../verify-gin/p1/main.go:21 (0x1030d504b)
	main.func2: d.GET("/boom", func(c *gin.Context) { panic("explode") })
...
[GIN] 2026/08/20 - 21:49:10 | 500 | 681.584µs |       127.0.0.1 | GET      "/boom"

2026/08/20 21:50:10 http: panic serving 127.0.0.1:54717: explode
goroutine 35 [running]:
net/http.(*conn).serve.func1()
...

4 · c.Param — path parameter ที่สั้นกว่า แต่กติกาต่างกัน

บท 37 เขียน {id} แล้วอ่านด้วย r.PathValue("id") · Gin เขียน :id แล้วอ่านด้วย c.Param("id") — แค่นั้น

mux.HandleFunc("GET /users/{id}",
  func(w http.ResponseWriter, r *http.Request) {
    id := r.PathValue("id")
    …
})

r.GET("/users/:id",
  func(c *gin.Context) {
    id := c.Param("id")
    …
})

ผมลง route สองอันพร้อมกัน — /users/:id กับ /users/me — แล้วยิงจริงห้าแบบ
handler ของ /users/me ตอบ gin.H{"who": "me (static)"} เฉย ๆ ส่วน handler ของ :id ตั้งใจตอบ ห้า field เพื่อดูหลายอย่างในนัดเดียว: id = c.Param("id") · nope = c.Param("nope") (ชื่อ param ที่ไม่มีอยู่จริง) · nope_n = len() ของค่านั้น · count กับ ok เป็นค่าคงที่ที่ใส่ไว้ให้เห็นการเรียงคีย์ของ gin.H

  GET    /users/me        -> 200  body={"who":"me (static)"}
  GET    /users/42        -> 200  body={"count":42,"id":"42","nope":"","nope_n":0,"ok":true}
  GET    /users/mex       -> 200  body={"count":42,"id":"mex","nope":"","nope_n":0,"ok":true}
  GET    /users/          -> 404  body=404 page not found
  GET    /users           -> 404  body=404 page not found

สามข้อสรุปจากห้าบรรทัดนี้:

1. static ชนะ param — /users/me เข้า handler ของ me ไม่ใช่ :id ที่ได้ id="me" · และไม่ใช่เพราะลงก่อนหลัง แต่เพราะ router มองว่า เจาะจงกว่าชนะ — เหมือน net/http เป๊ะ (แต่ /users/mex ที่แค่ขึ้นต้นเหมือนกัน ตกไปที่ :id ตามปกติ)
2. c.Param("nope") คืนสตริงว่าง ไม่ panic — nope_n คือ len() ของมัน ได้ 0 พฤติกรรมเดียวกับ r.PathValue คือไม่มีตัวที่สองบอก ok พิมพ์ชื่อ param ผิดจึงเงียบสนิท ไม่มี error ให้เห็น
3. /users/ ได้ 404 ไม่ใช่ id="" — :id ต้องมีอย่างน้อยหนึ่งตัวอักษร มันไม่เข้า handler เลย เพราะฉะนั้นอย่าเขียน if id == "" { … } เพื่อกันเคสนี้ — โค้ดนั้นจะไม่มีวันทำงาน

5 · Query / DefaultQuery / GetQuery — ทำไมต้องมีสามตัว

query string คือส่วนหลัง ? เช่น /search?q=go — เขียนเป็นคู่ key=value ต่อกันด้วย & ธรรมเนียมของ REST API คือใช้ query สำหรับ filter / sort / paginate (กรอง / เรียง / แบ่งหน้า) ส่วน path เอาไว้ระบุตัวของ ข้อมูลที่จะหยิบ — /users/42 คือ "ผู้ใช้คนที่ 42" ส่วน /users?dept=hr คือ "ผู้ใช้ทั้งหมด แต่กรองเอาเฉพาะแผนก hr"
Gin ให้มาสามเมธอดสำหรับอ่าน query ซึ่งดูซ้ำซ้อนจนกว่าจะเจอเคสที่สาม

r.GET("/search", func(c *gin.Context) {
    v, ok := c.GetQuery("q")
    c.JSON(200, gin.H{
        "Query":        c.Query("q"),
        "DefaultQuery": c.DefaultQuery("q", "x"),
        "GetQuery_val": v,
        "GetQuery_ok":  ok,
        "Query_len":    len(c.Query("q")),
    })
})

// ยิงสามแบบ: /search?q=go   ·   /search   ·   /search?q=

GET /search?q=go   -> {"DefaultQuery":"go","GetQuery_ok":true, "GetQuery_val":"go","Query":"go","Query_len":2}
GET /search        -> {"DefaultQuery":"x", "GetQuery_ok":false,"GetQuery_val":"",  "Query":"","Query_len":0}
GET /search?q=     -> {"DefaultQuery":"",  "GetQuery_ok":true, "GetQuery_val":"",  "Query":"","Query_len":0}

6 · r.Group — versioning ที่ไม่ต้องพิมพ์ /api/v1 ห้ารอบ

สไลด์บอกว่า API ควรมีเวอร์ชันใน path: /api/v1/users → วันหนึ่งเปลี่ยน contract ก็เปิด /api/v2/users ขนานกันไปโดยไม่ทำ client เก่าพัง
ปัญหาคือถ้าพิมพ์ prefix เองทุก route คุณจะพิมพ์ตกสักตัวแน่นอน และมันจะไม่ error ให้ด้วย — แค่กลายเป็น 404 เงียบ ๆ · r.Group แก้ปัญหานี้ตรง ๆ

r := gin.Default()

v1 := r.Group("/api/v1")
v1.GET("/recipes",      listRecipes)
v1.POST("/recipes",     createRecipe)
v1.GET("/recipes/:id",  getRecipe)
v1.PUT("/recipes/:id",  updateRecipe)
v1.DELETE("/recipes/:id", deleteRecipe)

listRecipes, createRecipe, … คือฟังก์ชันที่คุณเขียนเองไว้ในไฟล์เดียวกัน หน้าตา func listRecipes(c *gin.Context) { … } — เขียนแยกเป็นชื่อแบบนี้แทนที่จะยัด func(c *gin.Context){…} ลงไปในบรรทัด route ทำให้ตาราง route ที่ Gin พิมพ์ออกมาอ่านรู้เรื่องด้วย:

[GIN-debug] GET    /api/v1/recipes           --> main.listRecipes (3 handlers)
[GIN-debug] POST   /api/v1/recipes           --> main.createRecipe (3 handlers)
[GIN-debug] GET    /api/v1/recipes/:id       --> main.getRecipe (3 handlers)
[GIN-debug] PUT    /api/v1/recipes/:id       --> main.updateRecipe (3 handlers)
[GIN-debug] DELETE /api/v1/recipes/:id       --> main.deleteRecipe (3 handlers)
--- v1.BasePath() = /api/v1

(บรรทัดสุดท้ายเป็นของผมเอง ไม่ใช่ของ Gin — ผมเรียก v1.BasePath() มาพิมพ์ เพื่อยืนยันว่า group จำ prefix อะไรไว้)

สังเกตสองอย่าง: (1) prefix /api/v1 ถูกเติมให้ตอน register ไม่ใช่ตอน request — ค่าที่เก็บไว้จริงคือ path เต็ม (2) path ที่ลงคือ /api/v1/recipes เท่านั้น ยิง /recipes เฉย ๆ ได้ 404

7 · หัวใจของบท — รีแฟกเตอร์โค้ดบท 37 เป็น Gin ทีละบรรทัด

รีแฟกเตอร์ แปลว่าเขียนโค้ดใหม่ให้อ่านง่ายขึ้น โดยผลลัพธ์ต้องเหมือนเดิมเป๊ะ ถ้าผลลัพธ์เปลี่ยน อันนั้นไม่เรียกรีแฟกเตอร์แล้ว เรียกว่าเปลี่ยนพฤติกรรม
เอา handler ที่คุณเขียนในบท 37 มาวางจริง ๆ แล้วแปลงทีละบรรทัด ห้ามเปลี่ยน behavior — เป้าหมายคือให้ response เหมือนเดิมทุกไบต์

สองก้อนข้างล่างเป็นท่อนกลางของ main() ไม่ใช่ไฟล์เต็ม ถ้าจะ copy ไปรัน ต้องมีของอีกสามอย่างในไฟล์เดียวกันด้วย: package main · import (ฝั่งซ้ายใช้ net/http + encoding/json · ฝั่งขวาใช้ net/http + github.com/gin-gonic/gin — ฝั่งขวายัง import "net/http" อยู่เพราะยังใช้ค่าคงที่ http.StatusOK) · และ struct User จากบท 37: type User struct { ID string `json:"id"`; Name string `json:"name"` }

mux := http.NewServeMux()

mux.HandleFunc("GET /api/v1/users/{id}",
 func(w http.ResponseWriter, r *http.Request) {

  id := r.PathValue("id")

  if id == "0" {
    w.Header().Set("Content-Type",
        "application/json; charset=utf-8")
    w.WriteHeader(http.StatusNotFound)
    json.NewEncoder(w).Encode(
        map[string]string{"error": "user not found"})
    return
  }

  w.Header().Set("Content-Type",
      "application/json; charset=utf-8")
  w.WriteHeader(http.StatusOK)
  json.NewEncoder(w).Encode(
      User{ID: id, Name: "Somchai"})
})

http.ListenAndServe(":8080", mux)

r := gin.Default()
v1 := r.Group("/api/v1")

v1.GET("/users/:id",
 func(c *gin.Context) {

  id := c.Param("id")

  if id == "0" {
    c.JSON(http.StatusNotFound,
        gin.H{"error": "user not found"})
    return
  }

  c.JSON(http.StatusOK,
      User{ID: id, Name: "Somchai"})
})

r.Run(":8080")

แปลทีละบรรทัด — จำตารางนี้พอ:

บรรทัดที่กำไรจริงคือแถวที่ห้า — สามบรรทัดเหลือหนึ่ง
และมันไม่ได้กำไรแค่ "สั้นกว่า" · จำบทเรียนเจ็บ ๆ จากบท 37 ได้ไหม — Header().Set() หลัง WriteHeader() จะไม่มีผล แบบเงียบสนิท ไม่ error ไม่ log ทำให้ Content-Type กลายเป็น text/plain โดยที่คุณไม่รู้ตัว
c.JSON ทำให้เขียนผิดลำดับไม่ได้ตั้งแต่แรก เพราะมันเป็นบรรทัดเดียว — นี่คือกำไรที่แท้จริง ไม่ใช่จำนวนบรรทัด

แล้ว response จริงเหมือนกันไหม? ผมยิงเทียบทั้งสี่เคส

=== net/http (แบบบท 37) ===
  GET    /api/v1/users/42     -> 200  Content-Type="application/json; charset=utf-8"
        body={"id":"42","name":"Somchai"}
  GET    /api/v1/users/0      -> 404  Content-Type="application/json; charset=utf-8"
        body={"error":"user not found"}
  POST   /api/v1/users/42     -> 405  Content-Type="text/plain; charset=utf-8"
        body=Method Not Allowed
  GET    /api/v1/nope         -> 404  Content-Type="text/plain; charset=utf-8"
        body=404 page not found

=== Gin (refactor แล้ว) ===
  GET    /api/v1/users/42     -> 200  Content-Type="application/json; charset=utf-8"
        body={"id":"42","name":"Somchai"}
  GET    /api/v1/users/0      -> 404  Content-Type="application/json; charset=utf-8"
        body={"error":"user not found"}
  POST   /api/v1/users/42     -> 404  Content-Type="text/plain"
        body=404 page not found
  GET    /api/v1/nope         -> 404  Content-Type="text/plain"
        body=404 page not found

8 · ราคาที่ Gin เก็บ — สามอย่างที่ต้องรู้ก่อนใช้ของจริง

ราคาที่ 1 — 405 กลายเป็น 404 (และเปิดคืนได้)

net/http ให้ 405 Method Not Allowed พร้อม header Allow ฟรีตั้งแต่บรรทัดแรก · Gin ปิดความสามารถนี้ไว้เป็น default
ผมรันเทียบชัด ๆ — HandleMethodNotAllowed ค่า default คือ false
(โปรแกรมทดสอบนี้ลง route ไว้สองเส้น: /only-post ลงไว้เฉพาะ POST กับ PUT ส่วน /users/:id ลงไว้เฉพาะ GET — จำไว้ตอนอ่านค่า Allow ข้างล่าง เพราะมันคือรายชื่อ method ที่ลงไว้กับ path นั้นเป๊ะ ๆ):

=== default (HandleMethodNotAllowed = false) ===
GET    /only-post   -> status=404  Content-Type="text/plain"  body=404 page not found
DELETE /users/42    -> status=404  Content-Type="text/plain"  body=404 page not found

=== r.HandleMethodNotAllowed = true ===
GET    /only-post   -> status=405  Allow="POST, PUT"  body=405 method not allowed
GET    /nope        -> status=404  body=404 page not found

แก้ด้วยบรรทัดเดียว: r.HandleMethodNotAllowed = true แล้ว Gin จะคำนวณ header Allow ให้เองด้วย
ทำไมมันถึงไม่เปิดให้เป็น default? เพราะการจะตอบ 405 ได้ router ต้องไปไล่ดูทุก method ที่ลงไว้กับ path นั้นก่อน = งานเพิ่มต่อ request ที่ miss — Gin เลือก "เร็วที่สุด" มากกว่า "ถูกต้องตาม HTTP ที่สุด" · เป็นการแลกที่ตั้งใจ ไม่ใช่บั๊ก

ราคาที่ 2 — 404 ของ Gin ไม่ใช่ JSON

สังเกต Content-Type ในผลรันข้างบน: 404 ของ Gin คือ "text/plain" เปล่า ๆ ไม่มี charset ต่อท้ายด้วยซ้ำ และ body คือข้อความ 404 page not found ไม่ใช่ JSON

แปลว่า API ของคุณที่ตั้งใจตอบ JSON ทุกเส้นทาง ตอบ JSON ไม่ครบ — เส้นทางที่พิมพ์ path ผิดจะได้ text กลับไป ฝั่ง client ที่เรียก res.json() จะพังเป็น parse error แทนที่จะเห็น error message ที่อ่านออก
แก้ด้วย r.NoRoute(...) ให้ตอบ JSON ของเราเอง:

r.NoRoute(func(c *gin.Context) {
    c.JSON(http.StatusNotFound, gin.H{"error": "route not found"})
})

ราคาที่ 3 — Gin panic ตอนลง route ในเคสที่ net/http รับได้สบาย

A: /users/:id      แล้วตามด้วย /users/me
B: /users/me       แล้วตามด้วย /users/:id
C: /users/:id      แล้วตามด้วย /users/:userId
D: /users/:id      แล้วตามด้วย /users/:id  (path เดิม method เดิม)
E: /swagger/*any   แล้วตามด้วย /swagger/foo
F: /users/:id (GET) แล้วตามด้วย /users/me (POST)
G: /a/*any/b       (wildcard ไม่อยู่ท้าย path)

[A: /users/:id then /users/me] OK (no panic)
[B: /users/me then /users/:id] OK (no panic)
[C: /users/:id then /users/:userId] PANIC: ':userId' in new path '/users/:userId' conflicts with existing wildcard ':id' in existing prefix '/users/:id'
[D: /users/:id twice (same path, same method)] PANIC: handlers are already registered for path '/users/:id'
[E: /swagger/*any then /swagger/foo] PANIC: '/foo' in new path '/swagger/foo' conflicts with existing wildcard '/*any' in existing prefix '/swagger/*any'
[F: /users/:id (GET) and /users/me (POST) - different methods] OK (no panic)
[G: wildcard not at end: /a/*any/b] PANIC: catch-all routes are only allowed at the end of the path in path '/a/*any/b'

แล้วคู่ไหนที่ Gin panic แต่ net/http ไม่ panic? ผมเอา pattern คู่เดียวกันไปลงทั้งสองฝั่ง — subtree/wildcard คู่กับ path เจาะจง:

=== A) net/http: mux.HandleFunc("GET /files/") + mux.HandleFunc("GET /files/foo") ===
  GET     /files/foo             -> 200  body="LITERAL foo"
  GET     /files/bar             -> 200  body="SUBTREE"
[net/http /files/ + /files/foo] OK (no panic)

=== B) gin: r.GET("/files/*any") + r.GET("/files/foo") ===
[gin /files/*any + /files/foo] PANIC: '/foo' in new path '/files/foo' conflicts with existing wildcard '/*any' in existing prefix '/files/*any'

net/http รับได้สบาย แล้วใช้กติกา "เจาะจงกว่าชนะ" ตัดสินตอน request — /files/foo ไปที่ literal, /files/bar ตกลง subtree
Gin ไม่ยอมให้มีสองอันนี้อยู่ด้วยกันตั้งแต่แรก เพราะ radix tree ของมัน ตัดสินใจว่า node นี้เป็น catch-all ไปแล้ว จะแตกลูกออกไปอีกไม่ได้
เคสนี้ไม่ใช่เคสสมมติ — มันคือเคสที่คุณจะเจอในบทเรียนถัดไปตอนเสียบ Swagger UI ที่ต้องลง /swagger/*any แล้วดันมี route /swagger/something อยู่ก่อน

9 · ก่อนขึ้น production — gin.SetMode(gin.ReleaseMode)

โค้ดเดียวกันเป๊ะ ต่างแค่เรียก SetMode หรือไม่
(./p5 เป็นโฟลเดอร์โปรแกรมทดสอบของผมอีกตัว ผมเขียนให้มันรับ argument ชื่อ release แล้วค่อยเรียก gin.SetMode(gin.ReleaseMode) — ไม่ใช่ความสามารถของ Gin แต่เป็นโค้ดที่ผมเขียนเองเพื่อรันเทียบสองโหมดจากไฟล์เดียว)

$ go run ./p5
>>> gin.Mode() = debug
[GIN-debug] [WARNING] Creating an Engine instance …
[GIN-debug] [WARNING] Running in "debug" mode. …
 - using env:	export GIN_MODE=release
 - using code:	gin.SetMode(gin.ReleaseMode)

[GIN-debug] GET    /ping   --> main.main.func1 (3 handlers)
[GIN] 2026/08/20 - 21:50:30 | 200 |     41µs | 127.0.0.1 | GET "/ping"

$ go run ./p5 release
>>> gin.Mode() = release
[GIN] 2026/08/20 - 21:50:31 | 200 |  36.75µs | 127.0.0.1 | GET "/ping"

จุดที่ต้องอ่านให้ออกคือ access log [GIN] ยังอยู่ (access log = บรรทัดที่บันทึกทุก request ที่เข้ามา — ใครยิงอะไร ได้ status อะไร ใช้เวลาเท่าไหร่)
เพราะมันมาจาก Logger middleware ไม่ได้มาจากโหมด debug — คนละเรื่องกัน
ตั้งผ่าน environment ก็ได้ผลเดียวกัน: export GIN_MODE=release ซึ่งเป็นวิธีที่ควรใช้ตอน deploy จริง เพราะไม่ต้องแก้โค้ดระหว่าง dev กับ prod

ทดสอบความเข้าใจ

อ้างอิง

• pkg.go.dev — gin — API reference ตัวจริง: ดู Context.Param, Context.Query, Context.GetQuery, Context.JSON และ field Engine.HandleMethodNotAllowed
• Gin — Quickstart · ตัวอย่างทางการ — gin.Default(), route group, gin.H
• GitHub — gin-gonic/gin — README บอกเองว่า router มาจาก httprouter เวอร์ชันดัดแปลง และไฟล์ tree.go ยังติด license header ของ httprouter
• julienschmidt/httprouter — อ่านหัวข้อ "Named parameters" และ "Catch-All parameters" เพื่อเข้าใจว่าทำไม *any ต้องอยู่ท้าย path เสมอ
• pkg.go.dev — net/http.ServeMux — อ่านหัวข้อ "Patterns" และ "Precedence" เทียบกับกติกาของ Gin ในบทนี้
• MDN — 405 Method Not Allowed — สเปกบอกว่า response 405 ต้อง มี header Allow ซึ่งเป็นเหตุผลว่าทำไม 404 ของ Gin ถึงไม่ตรงสเปก
• บทเรียน 37 — โค้ดต้นทางที่เอามารีแฟกเตอร์ในหัวข้อ 7 · บทเรียน 13 — struct tag ที่ c.JSON ใช้อยู่ข้างใน