net/http — เซิร์ฟเวอร์ตัวแรก ไม่ใช้ framework

1 · เซิร์ฟเวอร์ที่เล็กที่สุดที่ทำงานได้จริง

ก่อนอื่นต้องตกลงกันว่า "HTTP server" คืออะไรในเชิงโค้ด — มันไม่ใช่ของวิเศษ
มันคือโปรแกรมที่ (1) จอง TCP port ไว้หนึ่งพอร์ต (พอร์ต = เลขช่องทางเข้าของเครื่อง เครื่องหนึ่งมีหลายพันช่อง แต่หนึ่งช่องมีโปรแกรมจองได้ทีละตัวเท่านั้น — ถ้าจองซ้ำจะได้ error address already in use · ส่วนโปรแกรมเดียวเปิดฟังหลายพอร์ตพร้อมกันได้ปกติ) · (2) นั่งรอจนมีใครต่อเข้ามา · (3) อ่านตัวอักษรที่เข้ามาว่าเป็นคำขออะไร · (4) เขียนตัวอักษรกลับไปตามรูปแบบที่ browser อ่านออก
ทั้งสี่ข้อ net/http ทำให้หมดแล้ว งานที่เหลือของเราคือข้อเดียว: บอกมันว่า path ไหนให้เรียกฟังก์ชันไหน
ฟังก์ชันที่ถูกเรียกตอน request เข้ามาตรง path นั้น เรียกว่า handler — จำคำนี้ไว้ เพราะตั้งแต่บรรทัดนี้ไปจนจบ Day 8 เราจะพูดถึงมันตลอด

โค้ดนี้คือฝั่งซ้ายของสไลด์ Day 8 หน้า 41 — เอาไปวางใน main.go แล้ว go run . ได้เลย

package main

import (
    "fmt"
    "net/http"
)

func main() {
    mux := http.NewServeMux()                     // 1. สมุดจดเส้นทาง

    mux.HandleFunc("GET /hello", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "hello from GET /hello")   // 3. เขียนคำตอบลง w
    })                                             // 2. จดว่า path นี้ใครรับ

    http.ListenAndServe(":8080", mux)             // 4. เปิดพอร์ตแล้วนั่งรอ
}

ยิงดู (ผมรันที่พอร์ต 8765 ตอนตรวจ — คุณรัน :8080 ก็เปลี่ยนเลขตาม):

$ curl -s -i http://127.0.0.1:8765/hello
HTTP/1.1 200 OK
Date: Thu, 20 Aug 2026 14:48:52 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8

hello from GET /hello

สี่ชิ้นนี้คือทั้งหมดที่ต้องเข้าใจ ผมขยายทีละชิ้น

2 · อ่าน signature ให้ขาด — ทำไม w ไม่มี * แต่ r มี

ก่อนอื่น signature แปลว่า "หน้าตาของฟังก์ชัน" — พารามิเตอร์ที่รับ + ค่าที่คืน เท่านั้น ชื่อไม่นับ (เพราะงั้นฟังก์ชันจะชื่ออะไรก็เอาไปใส่ HandleFunc ได้ ขอแค่รับ/คืนตรงกัน)
และบรรทัดนี้จะตามคุณไปทุกที่ในชีวิตการเขียน Go backend:

func(w http.ResponseWriter, r *http.Request)

คำถามที่มือใหม่ทุกคนถาม (และส่วนใหญ่ถูกตอบว่า "จำ ๆ ไปเถอะ") คือ ทำไมตัวหนึ่งมีดาว ตัวหนึ่งไม่มี
คำตอบไม่ใช่เรื่องสไตล์ — มันคือของคนละชนิดกันเลย ผมพิสูจน์ให้ดู

w เป็น interface ไม่ใช่ struct

เปิดดูของจริงด้วย go doc (ตัดคอมเมนต์ยาว ๆ ออก):

$ go doc net/http.ResponseWriter

type ResponseWriter interface {
    Header() Header
    Write([]byte) (int, error)
    WriteHeader(statusCode int)
}

มีแค่สาม method — นี่คือ interface ตามบทเรียน 10 เป๊ะ ๆ
และค่า interface ใน Go ถือ pointer ของของจริงไว้ข้างในอยู่แล้ว การใส่ * ทับลงไปอีกจึงไม่ได้อะไรเพิ่ม (และทำให้เรียก method ไม่ได้ตรง ๆ ด้วย)

พิสูจน์ว่ามันเป็น interface จริง — ผมพิมพ์ ชนิดจริงของ w ในสองสถานการณ์
(./wr, ./lasrv, ./conflict ที่จะเห็นต่อจากนี้ คือโฟลเดอร์ที่ผมใช้ตรวจเอง ไม่ต้องมีในเครื่องคุณ — ดูผลรันอย่างเดียวพอ)

func h(w http.ResponseWriter, r *http.Request) {
    fmt.Printf("  ชนิดจริงของ w = %T\n", w)
    fmt.Fprintln(w, "hi")
}

$ go run ./wr
ยิงผ่าน httptest:
  ชนิดจริงของ w = *httptest.ResponseRecorder
ยิงผ่าน server จริง:
  ชนิดจริงของ w = *http.response

โค้ด handler ตัวเดียวกัน แต่ w เป็นคนละชนิดกันเลย
ตอนรัน server จริง Go ยัด *http.response (ตัวที่เขียนลง TCP socket จริง) เข้ามา · ตอนเทส httptest ยัด *httptest.ResponseRecorder (ตัวที่เก็บลง buffer ใน RAM) เข้ามา
นี่คือเหตุผลทั้งหมดที่ handler ของเราเทสได้โดยไม่ต้องเปิดพอร์ต — และถ้า ResponseWriter เป็น struct ธรรมดา เรื่องนี้จะเป็นไปไม่ได้เลย

r เป็น struct — ก้อนใหญ่ที่ห้ามคัดลอก

ผมวัดขนาดจริงด้วย unsafe.Sizeof บนเครื่องเดียวกัน:

$ go run ./wr
unsafe.Sizeof(http.Request{})      = 304 bytes
unsafe.Sizeof(&http.Request{})     = 8 bytes (pointer)
unsafe.Sizeof(interface ค่า w)     = 16 bytes

ถ้า signature เป็น r http.Request (ไม่มีดาว) ทุก ๆ request ที่เข้ามา Go จะต้องคัดลอก 304 ไบต์นั้นทั้งก้อน ทุกครั้งที่ส่งต่อให้ handler
แย่กว่าเรื่องความเร็วคือ ตัวสำเนาจะแก้อะไรไม่ถึงต้นฉบับ

เรื่องนี้จะสำคัญมากตอนเจอ middleware — คำนี้แปลว่า ฟังก์ชันที่ห่อ handler อีกชั้น เพื่อทำงานบางอย่างก่อน/หลัง handler ตัวจริง (เช่น log, เช็ค token) เราจะเขียนของจริงกันในบทเรียน 39
วิธีที่ middleware ส่งข้อมูลลงไปให้ handler ชั้นในคือเปลี่ยนตัว r ที่ชั้นในจะได้รับ เช่นการแนบ context ลง request (บทเรียน 25) — ถ้าแต่ละชั้นได้แค่สำเนา ชั้นในก็จะได้ของเก่าเสมอ ทั้ง pattern ก็พังทันที
นี่คือกฎเดียวกับบทเรียน 7 ที่เคยเจอมาแล้ว แค่คราวนี้เจอในของจริง

แล้ว HandleFunc เกี่ยวอะไร

จริง ๆ แล้ว net/http รู้จักแค่ interface เดียวชื่อ Handler:

$ go doc net/http.Handler
type Handler interface {
    ServeHTTP(ResponseWriter, *Request)
}

$ go doc net/http.HandlerFunc
type HandlerFunc func(ResponseWriter, *Request)
    The HandlerFunc type is an adapter to allow the use of ordinary
    functions as HTTP handlers.

func (f HandlerFunc) ServeHTTP(w ResponseWriter, r *Request)
    ServeHTTP calls f(w, r).

อ่านสามบรรทัดนี้ช้า ๆ แล้วจะเห็นทริกที่สวยมากของ Go: HandlerFunc คือ ชนิดที่มี underlying type เป็นฟังก์ชัน (บทเรียน 9) และมันติด method ServeHTTP ที่ทำแค่ "เรียกตัวเอง"
เพราะแบบนี้ ฟังก์ชันธรรมดาถึงกลายเป็น Handler ได้ โดยไม่ต้องประกาศ struct — HandleFunc ก็แค่ห่อฟังก์ชันที่เราส่งไปด้วย HandlerFunc(...) แล้วจดลงตาราง

3 · pattern "GET /hello" — ของใหม่ที่มาพร้อม Go 1.22

ก่อน Go 1.22 ServeMux ดูแต่ path — จะกรอง method ต้องเขียน if r.Method != "GET" { ... } เองในทุก handler
ตั้งแต่ 1.22 ใส่ method ไว้หน้า path ในสตริงเดียวกันได้เลย และ mux จะจัดการ method ที่ไม่ตรงให้เอง

$ curl -s -i         http://127.0.0.1:8765/hello   # GET  ปกติ
$ curl -s -i -X POST http://127.0.0.1:8765/hello   # POST
$ curl -s -i -X OPTIONS http://127.0.0.1:8765/hello
$ curl -s -I         http://127.0.0.1:8765/hello   # -I ตัวใหญ่ = ยิง HEAD

$ curl -s -i http://127.0.0.1:8765/hello
HTTP/1.1 200 OK
Content-Length: 22
Content-Type: text/plain; charset=utf-8

hello from GET /hello

$ curl -s -i -X POST http://127.0.0.1:8765/hello
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD
Content-Type: text/plain; charset=utf-8
X-Content-Type-Options: nosniff
Content-Length: 19

Method Not Allowed

$ curl -s -i -X OPTIONS http://127.0.0.1:8765/hello
HTTP/1.1 405 Method Not Allowed
Allow: GET, HEAD
...
Method Not Allowed

$ curl -s -I http://127.0.0.1:8765/hello
HTTP/1.1 200 OK
Date: Thu, 20 Aug 2026 14:50:58 GMT
Content-Length: 22
Content-Type: text/plain; charset=utf-8

สตริง pattern พิมพ์ผิดนิดเดียว = พังคนละแบบ

"GET /hello" เป็นสตริงธรรมดา — compiler ไม่ช่วยตรวจให้เลย ผมเลยลองพิมพ์ผิดทุกแบบที่คนพิมพ์ผิดกันจริง แล้วดูว่าเกิดอะไร

4 · {id} ใน path และ r.PathValue

ของจริงเราไม่ได้มีแค่ /hello — เราต้องการ /users/1, /users/2, … โดยเขียน handler ตัวเดียว
Go 1.22 ให้ใส่ ปีกกาลงใน pattern แล้วดึงค่าออกมาด้วย r.PathValue

mux.HandleFunc("GET /users/{id}", func(w http.ResponseWriter, r *http.Request) {
    fmt.Fprintf(w, "id=%q missing=%q\n", r.PathValue("id"), r.PathValue("nope"))
})

$ curl -s -i http://127.0.0.1:8765/users/42
HTTP/1.1 200 OK
...
id="42" missing=""

$ curl -s -i http://127.0.0.1:8765/users/42/posts
HTTP/1.1 404 Not Found
X-Content-Type-Options: nosniff
...
404 page not found

สามข้อสังเกตจากผลรันข้างบน:

1. key ที่ไม่มีคืนสตริงว่าง ไม่ panic และไม่มีตัวที่สองแบบ value, ok
r.PathValue("nope") ได้ "" เฉย ๆ — แปลว่าถ้าคุณพิมพ์ชื่อ key ผิด (ลง {id} แต่อ่าน PathValue("ID")) โค้ดจะทำงานต่อด้วยสตริงว่าง แล้วไปพังลึก ๆ ในชั้น database แทน ชื่อใน pattern กับชื่อที่อ่านต้องตรงกันเป๊ะ

2. ทุกค่าที่ได้เป็น string เสมอ — /users/abc ก็เข้า handler ได้ ถ้าโค้ดต้องการตัวเลขก็ต้อง strconv.Atoi เองแล้วตอบ 400 เมื่อแปลงไม่ได้ (routing ไม่ใช่ validation)

3. {id} กินได้แค่ segment เดียว — /users/42/posts ไม่ match จึงได้ 404 ถ้าอยากให้กินทั้งหางใช้ {path...} (มีจุดสามจุด):

// pattern: "GET /static/{path...}"
$ curl -s -i http://127.0.0.1:8767/static/css/app.css
HTTP/1.1 200 OK
...
path...="css/app.css" url="/static/css/app.css"

$ curl -s -i http://127.0.0.1:8767/static/
HTTP/1.1 200 OK
...
path...="" url="/static/"

ลง /users/{id} คู่กับ /users/me ชนกันไหม

ไม่ชน และตัวที่เจาะจงกว่าชนะ — ผมลง {id} ก่อน me ด้วยซ้ำ:

$ curl -s -i .../users/me
HTTP/1.1 200 OK
this is /users/me (literal)

$ curl -s -i .../users/42
HTTP/1.1 200 OK
id="42" missing=""

$ go run ./conflict
registered GET /users/{id}
panic: pattern "GET /users/{name}"
conflicts with pattern "GET /users/{id}":
  GET /users/{name} matches the same
  requests as GET /users/{id}

กรณีที่ทับกันบางส่วนแต่ไม่มีใครเจาะจงกว่า ข้อความ panic ยังยกตัวอย่าง path ที่ชนให้ดูด้วย ซึ่งช่วยชีวิตมาก:

$ go run ./conflict2
registered GET /a/{x}/c
panic: pattern "GET /a/b/{y}" conflicts with pattern "GET /a/{x}/c":
	GET /a/b/{y} and GET /a/{x}/c both match some paths, like "/a/b/c".
	But neither is more specific than the other.
	GET /a/b/{y} matches "/a/b/y", but GET /a/{x}/c doesn't.
	GET /a/{x}/c matches "/a/x/c", but GET /a/b/{y} doesn't.

5 · ตอบ JSON — และลำดับสามบรรทัดที่ห้ามสลับ

API จริงตอบ JSON ไม่ใช่ text ธรรมดา และเครื่องมือคือ encoding/json จาก บทเรียน 13 ตัวเดิม
แต่มีทางเลือกสองทาง และผมอยากให้เลือกทางที่สอง:

ทีนี้ประเด็นสำคัญ: Encode ไม่ได้บอก client ว่านี่คือ JSON
ถ้าไม่ set Content-Type เอง Go จะเดาจาก 512 ไบต์แรกของ body (ฟังก์ชัน http.DetectContentType) และมันเดา JSON ไม่ออก:

DetectContentType(json bytes) = "text/plain; charset=utf-8"
encoded bytes = "{\"id\":\"7\",\"name\":\"Somchai\"}\n"

$ curl -s -i http://127.0.0.1:8765/json-nosniff
HTTP/1.1 200 OK
Content-Length: 28
Content-Type: text/plain; charset=utf-8

{"id":"7","name":"Somchai"}

body เป็น JSON ถูกต้องทุกตัวอักษร แต่ป้ายบอกว่าเป็น text/plain — client บางตัวก็ยังอ่านได้ แต่บางตัว (เช่น fetch ที่เช็ค Content-Type หรือ SDK ที่ generate มา) จะปฏิเสธ แล้วคุณจะหาสาเหตุไม่เจอเพราะ body ดูถูกทุกอย่าง

ทางแก้คือ set เอง — แต่ ต้อง set ให้ถูกจังหวะ ผมรันเทียบให้ดูสองแบบ:

w.Header().Set("Content-Type",
    "application/json; charset=utf-8")
w.WriteHeader(http.StatusCreated)
json.NewEncoder(w).Encode(u)

$ curl -s -i .../json-before
HTTP/1.1 201 Created
Content-Type: application/json; charset=utf-8
Content-Length: 28

{"id":"7","name":"Somchai"}

w.WriteHeader(http.StatusCreated)
w.Header().Set("Content-Type",
    "application/json; charset=utf-8")  // สาย
json.NewEncoder(w).Encode(u)

$ curl -s -i .../json-after
HTTP/1.1 201 Created
Content-Length: 28
Content-Type: text/plain; charset=utf-8

{"id":"7","name":"Somchai"}

6 · หัวใจของบท — ResponseWriter เขียนได้ครั้งเดียว

ทุกอย่างในหัวข้อ 5 มาจากกฎเดียวกัน และกฎนี้คือสิ่งที่ผมอยากให้จำจากบทนี้มากที่สุด
HTTP response ส่งออกเรียงลำดับ: status line → headers → body พอ byte แรกของ status line ออกจากเครื่องไปแล้ว มันดึงกลับไม่ได้ — ไม่ใช่ข้อจำกัดของ Go แต่เป็นข้อจำกัดของโปรโตคอล
"เขียนได้ครั้งเดียว" หมายถึงอะไรกันแน่: body จะเขียนกี่ครั้งก็ได้ (Write ต่อกันไปเรื่อย ๆ ได้) — ที่ส่งได้ครั้งเดียวคือ status + header ทั้งชุด ซึ่งออกไปพร้อมกันทีเดียวตอน WriteHeader

เวลาเดินจากบนลงล่าง — เส้นประคือ "จุดไม่ย้อนกลับ"

  w.Header().Set(...)     แก้ได้ตามใจ ยังไม่มีอะไรออกจากเครื่อง
        │
  ─ ─ ─ ┼ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─
        │  w.WriteHeader(201)   ← status + header ทั้งชุด ถูกส่งออกไปแล้ว
        ▼
  w.Header().Set(...)     สาย — ไม่มีผล ไม่มี error ไม่มี log
  w.WriteHeader(400)      สาย — ไม่มีผล แต่ มี log ฝั่ง server
  w.Write(...)            ต่อ body ได้เรื่อย ๆ ตามปกติ

แล้วถ้าไม่เคยเรียก WriteHeader เลยล่ะ? เอกสารของ ResponseWriter.Write ตอบไว้ว่า: "If WriteHeader has not yet been called, Write calls WriteHeader(http.StatusOK)"
แปลว่า การเขียน body ครั้งแรก = การประกาศ 200 โดยปริยาย — และนี่แหละคือกับดัก

func broken(w http.ResponseWriter, r *http.Request) {
    json.NewEncoder(w).Encode(map[string]string{"error": "id ต้องเป็นตัวเลข"})
    w.WriteHeader(http.StatusBadRequest)
}

=== RUN   TestBroken
    main_test.go:19: w.Code = 200
    main_test.go:20: Content-Type = "text/plain; charset=utf-8"
    main_test.go:21: body = "{\"error\":\"id ต้องเป็นตัวเลข\"}\n"
--- PASS: TestBroken (0.00s)

$ curl -s -i http://127.0.0.1:8765/late-status
HTTP/1.1 200 OK
Content-Length: 37
Content-Type: text/plain; charset=utf-8

body written first
after WriteHeader

2026/08/20 21:51:17 http: superfluous response.WriteHeader call from main.main.func8 (main.go:60)

ทางแก้: return ทุกครั้งที่ตอบเสร็จ

สาเหตุที่แท้จริงของกับดักนี้ไม่ใช่ "สลับสองบรรทัด" — ของจริงมันหน้าตาแบบนี้:

u, ok := users[r.PathValue("id")]
if !ok {
    writeJSON(w, 404, errNotFound)
    // ← ลืม return ตรงนี้
}
writeJSON(w, 200, u)   // วิ่งต่อเสมอ!

u, ok := users[id]
if !ok {
    writeJSON(w, 404, errNotFound)
    return                    // ← ขาดไม่ได้
}
writeJSON(w, 200, u)

7 · ListenAndServe คืน error เสมอ — อย่ากลืนมัน

โค้ดในหัวข้อ 1 ผมเขียน http.ListenAndServe(":8080", mux) ลอย ๆ โดยไม่รับค่าที่มันคืน — ซึ่ง Go ยอมให้ทำ และนั่นคือปัญหา
ผมรันสามสถานการณ์ให้ดูว่ามันคืนอะไรบ้าง:

$ go run ./lasrv
// เปิด server ตัวที่สองทับพอร์ตที่ตัวแรกจองอยู่
srv2 return: listen tcp 127.0.0.1:8971: bind: address already in use
srv2 err == nil ? false

// สั่งปิดตัวแรกอย่างสุภาพด้วย srv.Shutdown()
srv1 return: http: Server closed | errors.Is(err, http.ErrServerClosed)=true

// ขอจองพอร์ต 80 ในฐานะ user ธรรมดา
port80 return: listen tcp 127.0.0.1:80: bind: permission denied

สรุปจากผลรัน: ListenAndServe ไม่เคยคืน nil ถ้ามันคืนค่าเมื่อไหร่แปลว่า server หยุดแล้ว และมีสองสาเหตุเท่านั้น — เปิดไม่ขึ้นตั้งแต่แรก หรือ ถูกสั่งปิด

http.ListenAndServe(":8080", mux)

log.Println("listening on :8080")
if err := http.ListenAndServe(":8080", mux);
    err != nil && !errors.Is(err, http.ErrServerClosed) {
    log.Fatal(err)
}

8 · เทส handler โดยไม่ต้องเปิดพอร์ต

ยังจำหัวข้อ 2 ได้ไหมว่า w เป็น interface? ตรงนี้แหละที่มันคืนกำไร
เราไม่ต้องรัน server ไม่ต้องยิง curl ไม่ต้องหาพอร์ตว่าง — แค่เอา ResponseWriter ปลอมยัดเข้าไปแล้วเรียก mux.ServeHTTP ตรง ๆ

w := httptest.NewRecorder()                          // ResponseWriter ปลอม (เก็บลง buffer)
req := httptest.NewRequest(http.MethodGet, "/users/1", nil)  // Request ปลอม
mux.ServeHTTP(w, req)                                // เรียกเข้า mux เหมือน request จริง

// จากนั้นอ่านผลจาก w ได้เลย — สามบรรทัดล่างนี้แค่โชว์ว่ามีอะไรให้อ่านบ้าง
// เวลาใช้จริงต้องเอาไปใส่ใน if/t.Errorf ไม่ใช่วางลอย ๆ แบบนี้
w.Code                        // int         เช่น 200
w.Body.String()               // string      body ทั้งก้อน
w.Header().Get("Content-Type")  // string      header ที่ handler set

สังเกตว่าเรายิงเข้า mux ไม่ใช่เรียก handler ตรง ๆ — ทำแบบนี้จะได้ทดสอบ routing และ pattern ของเราไปพร้อมกัน ซึ่งจากหัวข้อ 3 เรารู้แล้วว่า pattern พิมพ์ผิดคือกับดักที่เงียบที่สุด

9 · แล้วทำไมยังต้องมี Gin

พออ่านมาถึงตรงนี้คำถามที่ควรผุดขึ้นคือ "ก็ครบแล้วนี่ จะ framework ไปทำไม"
คำตอบที่ซื่อสัตย์คือ ครบจริงสำหรับ API เล็ก ๆ — ของที่ Gin ให้เพิ่มคือของที่ เขียนเองได้แต่ต้องเขียนซ้ำทุกโปรเจกต์

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

type User struct {
    ID   string `json:"id"`
    Name string `json:"name"`
}

var users = map[string]User{"1": {ID: "1", Name: "Somchai"}}

// writeJSON คือตัวที่เขียนไว้ตั้งแต่ข้อ 2 — Header().Set → WriteHeader → Encode

func NewMux() *http.ServeMux {
    mux := http.NewServeMux()

    mux.HandleFunc("GET /health", func(w http.ResponseWriter, r *http.Request) {
        writeJSON(w, http.StatusOK, map[string]string{"status": "ok"})
    })

    mux.HandleFunc("GET /users/{id}", func(w http.ResponseWriter, r *http.Request) {
        u, ok := users[r.PathValue("id")]
        if !ok {
            writeJSON(w, http.StatusNotFound, map[string]string{"error": "user not found"})
            return
        }
        writeJSON(w, http.StatusOK, u)
    })

    return mux
}

func main() {
    log.Println("listening on 127.0.0.1:8080")
    if err := http.ListenAndServe("127.0.0.1:8080", NewMux()); err != nil {
        log.Fatal(err)
    }
}

tests := []struct {
    name, method, path, wantBody string
    wantCode int
}{
    {"health ตอบ ok", http.MethodGet, "/health", `{"status":"ok"}`, http.StatusOK},
    {"เจอ user", http.MethodGet, "/users/1", `{"id":"1","name":"Somchai"}`, http.StatusOK},
    {"ไม่เจอ user", http.MethodGet, "/users/999", `{"error":"user not found"}`, http.StatusNotFound},
    {"method ผิด", http.MethodDelete, "/users/1", "Method Not Allowed", http.StatusMethodNotAllowed},
}

for _, tc := range tests {
    t.Run(tc.name, func(t *testing.T) {
        w := httptest.NewRecorder()          // ← ใน t.Run เท่านั้น
        req := httptest.NewRequest(tc.method, tc.path, nil)
        mux.ServeHTTP(w, req)

        if w.Code != tc.wantCode {
            t.Fatalf("code = %d, want %d (body=%s)", w.Code, tc.wantCode, w.Body.String())
        }
        if got := strings.TrimSpace(w.Body.String()); got != tc.wantBody {
            t.Errorf("body = %q, want %q", got, tc.wantBody)
        }
    })
}

$ go test -v ./api/
=== RUN   TestAPI
=== RUN   TestAPI/health_ตอบ_ok
    main_test.go:39: code=200 ct="application/json; charset=utf-8" allow="" body={"status":"ok"}
=== RUN   TestAPI/เจอ_user
    main_test.go:39: code=200 ct="application/json; charset=utf-8" allow="" body={"id":"1","name":"Somchai"}
=== RUN   TestAPI/ไม่เจอ_user
    main_test.go:39: code=404 ct="application/json; charset=utf-8" allow="" body={"error":"user not found"}
=== RUN   TestAPI/method_ผิด
    main_test.go:39: code=405 ct="text/plain; charset=utf-8" allow="GET, HEAD" body=Method Not Allowed
--- PASS: TestAPI (0.00s)
PASS
ok  	w37/api	0.448s

อ้างอิง

• pkg.go.dev — net/http.ServeMux — อ่านหัวข้อ "Patterns" ให้จบ: กติกา method, {wildcard}, {$} และนิยามของคำว่า "เจาะจงกว่า" (precedence)
• Go Blog — Routing Enhancements for Go 1.22 — ทีม Go อธิบายเองว่าทำไมถึงเพิ่ม method กับ wildcard เข้า ServeMux และตัดสินใจเรื่อง 307 อย่างไร
• pkg.go.dev — ResponseWriter — ประโยคสำคัญอยู่ใน doc ของ Write: ถ้ายังไม่เรียก WriteHeader มันจะเรียก WriteHeader(StatusOK) ให้เอง
• pkg.go.dev — Request.PathValue · SetPathValue — คืนสตริงว่างเมื่อไม่มี key ที่ขอ
• pkg.go.dev — ListenAndServe · ErrServerClosed — "ListenAndServe always returns a non-nil error"
• pkg.go.dev — net/http/httptest — NewRecorder และ NewRequest (เรื่องเต็มอยู่บทเรียน 40)
• MDN — 405 Method Not Allowed — สเปกบอกว่า response 405 ต้องมี header Allow ซึ่งอธิบายว่าทำไม Go ใส่ให้เอง