本章目標

學完本章後，你將能夠：

1. 用 send lifecycle 判斷誰能 close channel
2. 分辨 sender、receiver、coordinator 的責任
3. 用 channel direction 表達能力限制
4. 設計多 sender 的安全關閉流程
5. 用 context 表達接收端提早停止，而不是關閉不屬於自己的 channel

【觀察】close channel 的核心風險是責任不清

Channel 關閉錯誤的核心問題是 ownership 沒定義清楚。接收端想停止讀取時關閉輸入 channel，多個 sender 中任一個 sender 自行 close，共用 channel 被外部任意 close，這些都可能造成 panic 或資料遺失。

責任不清的示例：

1func Consume(input chan Event) {
2    defer close(input)
3
4    for event := range input {
5        handle(event)
6    }
7}

這段程式的問題是 Consume 只是 receiver，卻關閉了 sender 還可能使用的 channel。只要上游晚一點送資料，就會出現 send on closed channel。

【判讀】close 的語意是不再有新值

close(ch) 的核心語意是「這個 channel 不會再收到新值」。它不是取消 goroutine 的通用手段，也不是釋放記憶體的必要動作。

單一 sender 可以安全 close：

 1func Produce(items []string) <-chan string {
 2    out := make(chan string)
 3
 4    go func() {
 5        defer close(out)
 6        for _, item := range items {
 7            out <- item
 8        }
 9    }()
10
11    return out
12}

這個 goroutine 是唯一 sender，因此它能保證迴圈結束後不再送出。receiver 可以用 range 讀到 channel 關閉為止：

1for item := range Produce([]string{"a", "b"}) {
2    fmt.Println(item)
3}

receiver 不需要 close out。接收完資料是 receiver 的狀態，不代表 sender 的生命週期已經結束。

【策略】先畫出 sender 和 receiver

Channel 設計的核心動作是先列出誰會 send、誰會 receive、誰知道所有 sender 已經結束。這比先決定 buffer 大小更重要。

如果無法回答「誰知道所有 sender 都結束」，就不應該 close 這個 channel。沒有 close 不一定是 bug；錯誤 close 才是更嚴重的問題。

【執行】多 sender 需要 coordinator 關閉

多個 goroutine 送往同一個 channel 時，關閉責任必須交給 coordinator。任一 sender 都不能單方面 close，因為其他 sender 可能還在送。

 1func Merge(inputs ...<-chan Event) <-chan Event {
 2    out := make(chan Event)
 3    var wg sync.WaitGroup
 4
 5    wg.Add(len(inputs))
 6    for _, input := range inputs {
 7        input := input
 8        go func() {
 9            defer wg.Done()
10            for event := range input {
11                out <- event
12            }
13        }()
14    }
15
16    go func() {
17        wg.Wait()
18        close(out)
19    }()
20
21    return out
22}

轉送 goroutine 只負責送資料。另一個 goroutine 等所有 sender 結束後才 close out。這把「送資料」和「宣告所有資料送完」分成兩個責任。

【執行】接收端提早停止要用 context

Receiver 提早停止的核心做法是通知上游停止，而不是關閉輸入 channel。context.Context 是 Go 服務中最常見的停止訊號。

 1func Consume(ctx context.Context, input <-chan Event) error {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            return ctx.Err()
 6        case event, ok := <-input:
 7            if !ok {
 8                return nil
 9            }
10            handle(event)
11        }
12    }
13}

Consume 可以因為 context 取消而退出，也可以因為 input 關閉而退出。它沒有 close input，因為 input 的 send lifecycle 不屬於它。

這個邊界在服務中很重要。HTTP handler、background worker、connection writer 都可能提早退出，但不能任意 close 上游仍可能使用的 channel。

【策略】channel direction 把能力寫進型別

Channel direction 的核心價值是限制函式能做的事。chan<- T 只能 send，<-chan T 只能 receive；這讓 ownership 更容易被讀者看見。

 1func StartWorker(ctx context.Context, jobs <-chan Job, results chan<- Result) {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            return
 6        case job, ok := <-jobs:
 7            if !ok {
 8                return
 9            }
10            results <- Process(job)
11        }
12    }
13}

StartWorker 只能從 jobs 收資料，只能往 results 送資料。它不能 close jobs，因為型別上就不是 sender；它是否能 close results 則要看它是不是唯一 sender。

方向限制不會自動解決所有權，但它能減少誤用，也讓 API 比註解更可靠。

【判讀】done channel 和 data channel 分開表達不同語意

停止訊號的核心語意應該和資料流分開。資料 channel 傳遞值；done channel 或 context 表示停止。把兩者混在一起會讓 close 的語意變模糊。

較清楚的設計：

 1type Worker struct {
 2    jobs <-chan Job
 3}
 4
 5func (w Worker) Run(ctx context.Context) {
 6    for {
 7        select {
 8        case <-ctx.Done():
 9            return
10        case job, ok := <-w.jobs:
11            if !ok {
12                return
13            }
14            process(job)
15        }
16    }
17}

jobs 關閉代表沒有更多 job。ctx.Done() 代表上層要求停止。這兩種退出原因不同，分開處理才能在 log、metric 或測試中看清楚。

【測試】測試 close 行為要避免靠 sleep

Channel ownership 的測試目標是確認 sender 結束後會 close、receiver 取消時不會 panic、多 sender 等全部完成才 close。這類測試應使用 channel 同步，不應依賴任意 sleep。

 1func TestProduceClosesOutput(t *testing.T) {
 2    output := Produce([]string{"a"})
 3
 4    if got := <-output; got != "a" {
 5        t.Fatalf("first value = %q, want %q", got, "a")
 6    }
 7
 8    _, ok := <-output
 9    if ok {
10        t.Fatalf("output should be closed after producer finishes")
11    }
12}

多 sender 測試可以讀到輸出 channel 關閉為止，確認所有值都收到：

 1func TestMergeClosesAfterAllInputsClose(t *testing.T) {
 2    a := make(chan Event, 1)
 3    b := make(chan Event, 1)
 4    a <- Event{ID: "a"}
 5    b <- Event{ID: "b"}
 6    close(a)
 7    close(b)
 8
 9    output := Merge(a, b)
10    got := map[string]bool{}
11    for event := range output {
12        got[event.ID] = true
13    }
14
15    if !got["a"] || !got["b"] {
16        t.Fatalf("merge should forward all events before closing")
17    }
18}

這個測試沒有固定等待時間。它把 channel close 本身當成同步訊號，結果更穩定。

本章不處理

本章先聚焦單一 Go process 內的 channel close 與 goroutine lifecycle；跨 process 的 ack、[consumer group](/go-advanced/backend/knowledge-cards/consumer-group) 與分散式訊號，會在下列章節再往外延伸：

• Backend：訊息佇列與事件傳遞
• Backend：可靠性驗證流程

和 Go 教材的關係

這一章承接的是 channel、goroutine 與 select 的協作；如果你要先回看語言教材，可以讀：

• Go：goroutine：輕量並發工作
• Go：channel：資料傳遞與 backpressure
• Go：select：同時等待多種事件
• Go：bounded worker pool

小結

Channel ownership 的核心是 send lifecycle。唯一 sender 可以在送完後 close；多 sender 需要 coordinator 統一 close；receiver 想停止時應使用 context，而不是關閉輸入 channel。把 sender、receiver、coordinator 分清楚，才能避免 send on closed channel、goroutine leak 與資料流混亂。

本模組承接入門篇的 goroutine、channel、select、mutex 基礎，進一步處理長時間運行服務會遇到的問題：誰能關閉 channel、worker 如何停止、channel 滿載時怎麼回應、共享 map/slice 如何避免 data race、工作量如何限制、入口速率如何控制。

章節列表

本模組使用的範例主題

本模組使用虛構的通知與工作處理服務作為範例。範例會包含背景 worker、事件佇列、即時推送、狀態 repository 與測試 fake。

範例只用來展示 Go 並發設計方法，不假設讀者正在維護任何特定專案。

本模組的 Go 核心概念

• 用 channel direction 表達 send-only 與 receive-only 能力。
• 用 context 作為 goroutine 停止訊號。
• 用 select 管理多種輸入與 ticker。
• 用 buffered channel 吸收短暫尖峰，但不把 buffer 當成容量規劃替代品。
• 用 mutex 保護共享 map/slice。
• 用 copy boundary 防止呼叫端修改內部狀態。
• 用 worker pool 控制同時執行數。
• 用 rate limiter 把過量輸入轉成可預期回應。
• 用 race detector 與 focused tests 驗證並發邊界。

學習重點

學完本模組後，你應該能判斷：

1. 哪個 goroutine 擁有 channel 的關閉責任
2. 一個長期 worker 停止時需要釋放哪些資源
3. channel 滿載時應該等待、回錯、丟棄還是降級
4. map、slice、pointer 何時會洩漏內部狀態
5. 什麼情況下 mutex 比 channel 更適合表達狀態擁有權
6. 什麼情況下需要 bounded worker pool
7. 入口過量時應排隊、限速、拒絕還是降級

本模組不處理

本模組不討論分散式鎖、actor framework 或高階 queue 系統。這些主題建立在本模組的基礎之上；本模組先把單一 Go process 內的 goroutine、worker、速率與共享資料邊界講清楚。外部 broker 與分散式流量治理會放在 Backend：訊息佇列與事件傳遞 與 Backend：部署平台與網路入口。

先備知識

• Go 入門：並發模型
• 知道 goroutine、channel、select、mutex 的基本用法

學習時間

預計 4-5 小時

本章目標

學完本章後，你將能夠：

1. 建立與使用 channel
2. 看懂 channel 的方向與資料型別
3. 理解 buffered channel 的 backpressure 意義
4. 分辨 blocking send 與 non-blocking send
5. 用 channel 畫出資料流

【觀察】channel 連接送出端與接收端

channel 的核心規則是：送出端用 <- 把值放入 channel，接收端用 <- 從 channel 取出值。以下範例建立一個傳遞 string 的 channel：

1messages := make(chan string)
2
3go func() {
4    messages <- "hello"
5}()
6
7msg := <-messages
8fmt.Println(msg)

make(chan string) 建立只能傳 string 的 channel。messages <- "hello" 是送出，msg := <-messages 是接收。

【判讀】channel 是同步點，不只是佇列

unbuffered channel 的核心規則是：送出和接收必須同時準備好，資料才會通過。這表示 channel 也是同步點。

1ch := make(chan int)
2
3go func() {
4    ch <- 1 // 等到有人接收才會繼續
5}()
6
7value := <-ch
8fmt.Println(value)

buffered channel 的核心規則是：buffer 未滿時送出不會阻塞，buffer 滿時送出會阻塞。

1jobs := make(chan Job, 10)
2jobs <- Job{ID: "1"}

buffer 大小不是隨便的數字。它代表系統允許累積多少尚未處理的工作；接收端處理速度跟不上時，buffer 會逐漸填滿，最後形成 backpressure 。

【策略】用方向限制表達所有權

channel direction 的核心規則是：函式簽名應限制自己只需要的能力。Go 可以用 channel direction 表達函式只讀或只寫：

1func producer(out chan<- Job) {
2    out <- Job{ID: "1"}
3}
4
5func consumer(in <-chan Job) {
6    job := <-in
7    handle(job)
8}

chan<- Job 表示只能送出，<-chan Job 表示只能接收。這是 API 層的保護：producer 不能讀取 channel，consumer 不能寫入 channel。

【執行】non-blocking send 的取捨

non-blocking send 的核心規則是：送不出去時立即走 fallback，不等待接收端。它適合「寧可丟棄或記錄，也不要卡住呼叫端」的情境。

1select {
2case jobs <- job:
3    logger.Info("job queued", "id", job.ID)
4default:
5    logger.Warn("job queue full", "id", job.ID)
6}

這個策略的代價是資料可能被丟棄，所以必須記錄 log 或回傳明確錯誤。若資料不能丟，就不要用 default；讓送出端阻塞或回傳「系統忙碌」會更誠實。

關閉 channel

關閉 channel 的核心規則是：由送出端關閉，表示不會再有新資料。接收端可以用 range 讀到 channel 關閉：

 1func producer(out chan<- int) {
 2    defer close(out)
 3    for i := 0; i < 3; i++ {
 4        out <- i
 5    }
 6}
 7
 8func consumer(in <-chan int) {
 9    for value := range in {
10        fmt.Println(value)
11    }
12}

接收端不應關閉自己沒有所有權的 channel；否則送出端可能在送資料時遇到 panic。

本章目標

學完本章後，你將能夠：

1. 分辨 blocking send 與 non-blocking send 的服務語意
2. 為 HTTP、worker、即時推送設計不同滿載策略
3. 判斷哪些事件可以丟、哪些不能丟
4. 為 drop 與 queue full 建立 log/metric
5. 測試 channel 滿載時的行為

【觀察】channel 滿載是容量訊號

Channel 滿載的核心意義是下游處理速度跟不上上游輸入速度。這可能是短暫尖峰，也可能是系統長期容量不足。

最直接的 send 會接受 backpressure ：

1events <- event

如果 events 沒有 buffer，或 buffer 已滿，sender 會等待 receiver。這能保留資料，但也可能讓 HTTP handler、connection writer 或其他 goroutine 卡住。

對批次 worker 來說，等待可能合理；對使用者 request 來說，無限等待通常會變成 timeout 或 goroutine 堆積。

【判讀】blocking send 表示願意等待

Blocking send 的核心語意是 sender 接受下游 backpressure 。資料不會被丟掉，但 sender 的生命週期會被 receiver 影響。

有 context 的 blocking send：

1func Enqueue(ctx context.Context, events chan<- Event, event Event) error {
2    select {
3    case events <- event:
4        return nil
5    case <-ctx.Done():
6        return ctx.Err()
7    }
8}

這種寫法仍然願意等待，但不會無限等待。若 request 被取消或 timeout，send 也會停止。

Blocking send 適合資料不能丟、上游能等待、且等待時間受 context 控制的情境。若沒有 context，blocking send 在服務入口通常風險較高。

【判讀】non-blocking send 表示立即選擇替代路徑

Non-blocking send 的核心語意是「能送就送，不能送就立刻走其他策略」。Go 常用 select 加 default 表達。

 1var ErrQueueFull = errors.New("event queue is full")
 2
 3func TryEnqueue(events chan<- Event, event Event) error {
 4    select {
 5    case events <- event:
 6        return nil
 7    default:
 8        return ErrQueueFull
 9    }
10}

這段程式不會等待 receiver。當 buffer 滿載時，呼叫端會立刻拿到 ErrQueueFull，並可以決定回 HTTP 錯誤、記錄 drop、或改走其他儲存。

Non-blocking send 不是比較進階的寫法。它只是把 backpressure 從「等待」改成「立即決策」。

【策略】先定義事件的保留等級

滿載策略的核心判斷是資料語意。每種事件都應先定義保留等級：必須保存、可降級、可覆蓋、可取樣，或可延後處理。這個等級決定 channel 滿載時要等待、回錯、丟棄、覆蓋或轉交可靠儲存。

這個表格的重點是要求每種事件都要有明確策略。若團隊只說「channel 滿了就 default」，通常代表資料語意還沒有想清楚。

【執行】HTTP 入口要把滿載轉成狀態碼

HTTP 入口的核心責任是把內部滿載轉成呼叫端能理解的結果。不要讓 request 一直等到 timeout，也不要把未接受的事件回成成功。

 1func EventHandler(events chan<- Event) http.HandlerFunc {
 2    return func(w http.ResponseWriter, r *http.Request) {
 3        event := Event{ID: r.Header.Get("X-Request-ID")}
 4
 5        if err := TryEnqueue(events, event); err != nil {
 6            if errors.Is(err, ErrQueueFull) {
 7                w.Header().Set("Retry-After", "5")
 8                http.Error(w, "event queue is full", http.StatusServiceUnavailable)
 9                return
10            }
11            http.Error(w, "event enqueue failed", http.StatusInternalServerError)
12            return
13        }
14
15        w.WriteHeader(http.StatusAccepted)
16    }
17}

202 Accepted 表示事件已被服務接受進入後續處理。503 Service Unavailable 表示服務目前無法接受更多事件，呼叫端可以稍後重試。

若事件不能丟，HTTP handler 應該回錯或寫入可靠儲存，不應假裝成功。

【執行】即時推送可以選擇 drop 或 disconnect

即時推送的核心問題是慢 client 不能拖住整個服務。若某個連線的 send buffer 滿了，服務要決定丟掉該訊息、丟掉舊訊息，還是關閉連線。

 1type Client struct {
 2    send chan Message
 3}
 4
 5func (c *Client) TrySend(message Message) bool {
 6    select {
 7    case c.send <- message:
 8        return true
 9    default:
10        return false
11    }
12}

呼叫端可以根據 false 決定策略：

1if ok := client.TrySend(message); !ok {
2    metrics.Inc("client_send_dropped")
3    logger.Warn("drop client message", "reason", "send_buffer_full")
4}

對狀態型 UI 來說，丟掉中間更新可能可以接受，因為下一次 snapshot 會補上最新狀態。對逐筆不可遺失訊息來說，應改用可靠佇列或明確斷線重連協定。

【策略】buffer 只能吸收短暫尖峰

Buffer 的核心作用是平滑短時間流量差，不是解決長期處理能力不足。把 channel buffer 調大，只是延後滿載時間，也可能增加記憶體與延遲。

1events := make(chan Event, 1024)

設計 buffer 時至少要考慮：

• 單筆事件大小
• producer 峰值速度
• consumer 穩定處理速度
• 允許排隊延遲
• 滿載時的回應策略

若 producer 每秒 1000 筆、consumer 每秒 100 筆，任何有限 buffer 都會滿。這時要改善 consumer 能力、增加 worker、做取樣、回錯或使用可靠 queue，而不是只調大數字。

【策略】丟棄一定要可觀測

Drop strategy 的核心要求是可觀測。只要系統選擇丟棄或降級，就應該留下 metric 或 structured log，否則資料遺失會變成隱性 bug。

 1func TryEnqueueWithMetrics(events chan<- Event, event Event, logger *slog.Logger) error {
 2    select {
 3    case events <- event:
 4        metrics.Inc("event_enqueue_success")
 5        return nil
 6    default:
 7        metrics.Inc("event_enqueue_dropped")
 8        logger.Warn("drop event",
 9            "reason", "queue_full",
10            "event_type", event.Type,
11            "subject_id", event.SubjectID,
12        )
13        return ErrQueueFull
14    }
15}

Log 適合保留單次事件脈絡，metric 適合觀察趨勢。若 drop rate 升高，代表服務正在降級；這應該能被監控看見。

【測試】滿載行為要直接測

Non-blocking send 的測試核心是先讓 channel 滿載，再確認函式立刻回錯。不要用 sleep 等待「可能會滿」。

1func TestTryEnqueueReturnsQueueFull(t *testing.T) {
2    events := make(chan Event, 1)
3    events <- Event{ID: "already_full"}
4
5    err := TryEnqueue(events, Event{ID: "next"})
6    if !errors.Is(err, ErrQueueFull) {
7        t.Fatalf("error = %v, want ErrQueueFull", err)
8    }
9}

Blocking send with context 也可以測：

 1func TestEnqueueStopsWhenContextCanceled(t *testing.T) {
 2    events := make(chan Event)
 3    ctx, cancel := context.WithCancel(context.Background())
 4    cancel()
 5
 6    err := Enqueue(ctx, events, Event{ID: "evt_1"})
 7    if !errors.Is(err, context.Canceled) {
 8        t.Fatalf("error = %v, want context canceled", err)
 9    }
10}

這些測試把滿載和取消變成可重現條件，不需要依賴時間推測。

本章不處理

本章先處理單一 process 內的滿載處理策略；當訊息需要持久化、重試或跨 process 傳遞時，會在下列章節再往外延伸：

• Backend：訊息佇列與事件傳遞
• Go 進階：Durable queue、outbox 與 idempotency

和 Go 教材的關係

這一章承接的是 channel backpressure 、worker capacity 與事件丟棄策略；如果你要先回看語言教材，可以讀：

• Go：channel：資料傳遞與 backpressure
• Go：select：同時等待多種事件
• Go：rate limiting 與 backpressure
• Go：多來源 event 融合

小結

非阻塞送出是服務策略，不是語法技巧。Channel 滿載時，系統必須明確選擇等待、回錯、丟棄、覆蓋或轉交可靠儲存。選擇之前先定義事件的保留等級，選擇之後補上 log、metric 與測試，才能讓 backpressure 成為可管理的服務行為。

本章目標

學完本章後，你將能夠：

1. 理解 select 的基本語法
2. 同時等待多個 channel
3. 用 ctx.Done() 停止事件迴圈
4. 用 ticker 建立定時工作
5. 理解 default 的 non-blocking 行為

【觀察】select 同時等待多個 channel

select 的核心規則是：多個 case 中哪個 channel 先 ready，就執行哪個 case。以下範例同時等待 job 和取消訊號：

 1func worker(ctx context.Context, jobs <-chan Job) {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            return
 6        case job := <-jobs:
 7            handle(job)
 8        }
 9    }
10}

這個 worker 不需要先固定等待 jobs，也不需要用輪詢檢查 context。select 會同時等待兩者。

【判讀】select loop 是長期 goroutine 的生命週期中心

長期 goroutine 的核心規則是：事件迴圈必須同時處理工作來源與退出訊號。只讀工作 channel 而不讀 ctx.Done()，goroutine 可能無法按上層要求停止。

 1func worker(ctx context.Context, jobs <-chan Job) {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            return
 6        case job, ok := <-jobs:
 7            if !ok {
 8                return
 9            }
10            handle(job)
11        }
12    }
13}

ok == false 表示 channel 已關閉。這讓 worker 在「上層取消」和「工作來源結束」兩種情境都能退出。

【策略】ticker case 要有 Stop

ticker 的核心規則是：建立 ticker 後要呼叫 Stop()，避免不再使用時仍保留 runtime 資源。

 1func cleanupLoop(ctx context.Context) {
 2    ticker := time.NewTicker(time.Minute)
 3    defer ticker.Stop()
 4
 5    for {
 6        select {
 7        case <-ctx.Done():
 8            return
 9        case <-ticker.C:
10            cleanup()
11        }
12    }
13}

這種模式常用於定期清理、同步、掃描或報表輸出。

【執行】default 建立 non-blocking select

default 的核心規則是：沒有任何 channel ready 時，立即執行 default。這會讓 select 不阻塞。

1select {
2case jobs <- job:
3    return nil
4default:
5    return ErrQueueFull
6}

這段程式嘗試把 job 放進 channel；如果 channel 不能立即接收，就回傳 ErrQueueFull。這適合保護呼叫端不要被背景佇列卡住。

不適合用 default 的情境是你其實需要等待結果：

1select {
2case result := <-results:
3    return result
4default:
5    return Result{} // 可能過早返回
6}

若結果是必要的，應該等待或設定 timeout，而不是直接 default。

timeout pattern

timeout 的核心規則是：需要等待但不能無限等待時，用 time.After 或 context timeout。

1select {
2case result := <-results:
3    return result, nil
4case <-time.After(2 * time.Second):
5    return Result{}, errors.New("timeout")
6}

在較大的系統中，通常更偏好 context.WithTimeout，讓 timeout 可以沿呼叫鏈傳遞。

概念位置

Release Channel 位在 artifact 發布與使用者取得之間，常見通道包含 internal、alpha、beta、stable、enterprise、nightly 與 rollback channel。

可觀察訊號

• 同一產品需要內測、公開測試與正式版本分流。
• 錯誤版本需要停止擴散或切回回復通道。
• 客戶端更新需要依風險分批推進。

接近真實服務的例子

桌面 app 先把 signed installer 推到 internal channel，驗證更新成功率後再推 beta channel，最後推 stable channel。若 stable 版本出現 crash，feed 可切回 rollback channel 或暫停更新。

設計責任

Release Channel 要定義通道用途、進入條件、artifact 命名、可見範圍、停損條件與回復路徑，讓版本擴散具備控制面。

本章目標

學完本章後，你將能夠：

1. 分辨 process、thread 與 goroutine 的角色
2. 理解 Go 並發與平行執行不是同一件事
3. 看懂為什麼 I/O 型服務特別適合 Go
4. 判斷什麼時候應該限制並發數
5. 了解 Redis 與 SQL 在高併發下為什麼要加邊界

【觀察】goroutine 由 Go runtime 管理

goroutine 是 Go runtime 管理的輕量工作單位，OS thread 則是作業系統實際排程的執行緒。你通常不會直接手動管理 goroutine 對應到哪一條 thread；Go runtime 會負責把很多 goroutine 排程到較少的 OS thread 上。

這表示兩件事：

• 啟動 goroutine 的成本比建立 thread 低得多。
• goroutine 很便宜，不代表下游資源也很便宜。

【判讀】並發和平行是不同層次

並發的核心意義是「很多工作在時間上交疊」，平行的核心意義是「真的同時在多個核心上跑」。Go 可以讓你很容易建立並發工作，但是否能同時跑在多核心上，還要看 runtime 排程、CPU 數量與工作型態。

對服務開發來說，這個差異很重要：

• I/O-bound 工作通常最適合並發化，因為大部分時間都在等網路、磁碟或外部服務。
• CPU-bound 工作不會因為你加很多 goroutine 就自動變快，反而可能因為排程與同步成本變複雜。

【策略】高併發的真正重點是限制下游

Go 的 goroutine 很容易開，但 Redis、SQL、HTTP API、檔案描述元與記憶體 buffer 都有容量上限。高併發設計的核心是替外部資源設邊界，讓 goroutine 數量、下游連線與排隊時間都保持可預期。

常見邊界包括：

• worker pool 限制同時處理的工作量
• semaphore 或 rate limit 限制入口速率
• timeout / deadline 避免單一請求卡太久
• queue 或 buffer 對短暫尖峰提供緩衝
• backpressure 讓上游看到真實壓力

【應用】Redis 與 SQL 都是 I/O 邊界

Redis 與 SQL 在 Go 裡通常都被當成 I/O 操作來看待：goroutine 負責並發發出請求，但真正的瓶頸通常在網路延遲、連線數、鎖競爭、索引、熱點 key 或 transaction 範圍。

這也是為什麼後面的資料存取章節會反覆強調：

• client 或 sql.DB 要共用，不要每個 request 都 new
• 每個操作都應該帶 context
• 讀取可以大量並發，但要有連線池和 timeout
• 寫入可以並發，但要注意衝突、重試與交易邊界
• 當下游開始飽和時，要有明確的拒絕、排隊或降級策略

【延伸】runtime 細節不必現在全背

本章先建立 runtime 閱讀模型：goroutine 很輕，thread 有成本，下游資源有上限，並發要設邊界。runtime 的完整內部實作可以留到 profiling 與效能診斷階段再深入。

更進一步的診斷與觀察，會在後面的 runtime profiling 與 goroutine leak 章節再補。

本章先處理

這一章先把 Go 的並發模型講清楚；真正落到資料庫與快取時，可以再看：

• Backend：資料庫與持久化：看 SQL、transaction、connection pool 與 schema 邊界如何承接服務壓力。
• Backend：快取與 Redis：看 Redis client、TTL、eviction、presence store 與 hot key 如何承接服務壓力。
• bounded worker pool：把並發數收斂成可控容量。