Concurrency on Tarragon

1.1 channel ownership 與關閉責任

Wed, 22 Apr 2026 00:00:00 +0000

Channel ownership 的核心規則是：能保證不再送出資料的一方，才有資格關閉 channel。建立 channel 的程式碼不一定是 owner；真正的 owner 是掌握 send lifecycle 的元件。

本章目標

學完本章後，你將能夠：

用 send lifecycle 判斷誰能 close channel
分辨 sender、receiver、coordinator 的責任
用 channel direction 表達能力限制
設計多 sender 的安全關閉流程
用 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 大小更重要。

角色	能力	close 責任
single sender	送出資料，知道自己何時結束	擁有 close 責任
receiver	接收資料，可能提早停止	透過 context 通知停止
coordinator	等待所有 sender 結束	擁有 close 責任
external caller	持有 channel reference 但不了解生命週期	不參與 close 決策

如果無法回答「誰知道所有 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) 與分散式訊號，會在下列章節再往外延伸：

和 Go 教材的關係

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

小結

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

4.1 goroutine：輕量並發工作

Wed, 22 Apr 2026 00:00:00 +0000

goroutine 是 Go 執行並發工作的基本單位。它的核心用途是讓一段函式和目前流程同時進行，但每個 goroutine 都必須有明確的退出條件，否則長時間程式會累積無法回收的背景工作。

本章目標

學完本章後，你將能夠：

用 go 啟動 goroutine
理解 goroutine 和一般函式呼叫的差異
判斷哪些工作適合放進 goroutine
為 goroutine 設計退出條件
避免 goroutine leak

【觀察】go 關鍵字啟動並發工作

go 的核心規則是：在函式呼叫前加上 go，該函式會在新的 goroutine 中執行，呼叫端不會等待它完成。

1func say(message string) {
2    fmt.Println(message)
3}
4
5func main() {
6    go say("background")
7    say("foreground")
8}

這段程式啟動一個背景 goroutine 執行 say("background")，主 goroutine 會繼續執行 say("foreground")。

【判讀】goroutine 需要明確完成保證

goroutine 的生命週期規則是：程式不會因為你啟動了 goroutine 就自動等待它完成。main() 結束時，整個 process 會結束，尚未完成的 goroutine 也會停止。

因此，這段程式可能看不到背景輸出：

1func main() {
2    go fmt.Println("background")
3}

主程式太快結束時，背景 goroutine 可能還沒得到執行機會。

需要等待結果時，應該使用 channel、sync.WaitGroup 或其他同步機制。

【策略】goroutine 適合等待型或獨立型工作

goroutine 使用的核心規則是：只有當工作能和目前流程並發進行，且生命週期可被管理時，才啟動 goroutine。

適合 goroutine 的工作：

工作類型	原因
等待 I/O	等檔案、網路、外部程序時不阻塞主流程
背景 worker	從 channel 收 job 並處理
定時任務	定期清理、同步或掃描
多個獨立請求	可同時發出、再收集結果

等待 I/O 的核心訊號是目前流程會花時間等外部回應，例如讀檔、呼叫 HTTP API、等待資料庫查詢或讀取 socket。這類工作放進 goroutine 後，呼叫端可以繼續處理其他事件，但仍然要用 context 或 channel 管理結果與取消。

背景 worker 的核心訊號是工作來自 queue 或 channel，而且處理時間和 request 生命週期分離。例如使用者送出匯入任務後，server 只先接受任務，後續由 worker 逐筆處理資料。這種 goroutine 通常需要明確的 job channel、錯誤回報與 shutdown 流程。

定時任務的核心訊號是行為按時間觸發，例如每分鐘清理過期 session、同步外部狀態或刷新快取。這類 goroutine 應使用 ticker 搭配 context，讓服務停止時可以一起退出。

多個獨立請求的核心訊號是多個工作彼此沒有順序依賴，例如同時查三個外部 API，最後合併結果。這類 goroutine 的重點是收集結果、限制並發數量，並在其中一個工作失敗時決定是否取消其他工作。

需要先補齊生命週期設計的情境：

只是想讓程式「看起來比較快」
沒有任何退出條件
呼叫端需要結果但沒有同步機制
多個 goroutine 會同時修改共享資料但沒有保護

【執行】用 WaitGroup 等待一組工作

sync.WaitGroup 的核心用途是等待一組 goroutine 完成。

 1func main() {
 2    var wg sync.WaitGroup
 3
 4    for i := 0; i < 3; i++ {
 5        wg.Add(1)
 6        go func(id int) {
 7            defer wg.Done()
 8            fmt.Println("worker", id)
 9        }(i)
10    }
11
12    wg.Wait()
13}

這段程式有三個關鍵：

動作	意義
`wg.Add(1)`	增加一個待完成工作
`defer wg.Done()`	goroutine 結束時標記完成
`wg.Wait()`	等待所有工作完成

id 作為參數傳入 goroutine，可以避免 loop 變數捕捉造成混淆。

長時間 goroutine 要能停止

長時間 goroutine 的核心規則是：迴圈中必須等待取消訊號或輸入 channel 關閉。

 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}

這個 worker 不會無限卡住；上層取消 context 或關閉 jobs channel，它都會退出。

設計檢查

需要結果時要有等待機制

需要結果或完成保證時，goroutine 應搭配 channel 或 WaitGroup。go doWork() 只負責啟動工作，結果收集與完成等待需要另外設計。

錯誤要有回報路徑

goroutine 裡的錯誤需要明確回報路徑。需要錯誤結果時，用 channel 傳回：

1errCh := make(chan error, 1)
2go func() {
3    errCh <- doWork()
4}()
5
6if err := <-errCh; err != nil {
7    return err
8}

長時間工作要有退出條件

長時間 worker 至少要監聽 context 或 channel close。永遠 for {} 會讓 goroutine 生命週期失去 owner，服務停止時也難以清理。

模組一：進階並發模式

Wed, 22 Apr 2026 00:00:00 +0000

Go 並發設計的核心是明確定義 ownership、生命週期、 backpressure 與共享狀態邊界。goroutine 很便宜，但失控的 goroutine、關閉錯誤的 channel、無限制堆積的 buffer，以及外洩的可變資料都會讓服務難以維護。

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

章節列表

章節	主題	關鍵收穫
1.1	channel ownership 與關閉責任	用 sender lifecycle 判斷誰能 close channel
1.2	select loop 的生命週期設計	同時處理輸入、ticker、取消與資源釋放
1.3	非阻塞送出與事件丟棄策略	把 channel 滿載轉成明確服務行為
1.4	共享狀態與複製邊界	用 lock、copy 與 owner method 保護可變資料
1.5	bounded worker pool	限制同時執行的工作量，避免 goroutine 無限制堆積
1.6	rate limiting 與 backpressure	用本地速率限制保護服務入口與下游依賴

本模組使用的範例主題

本模組使用虛構的通知與工作處理服務作為範例。範例會包含背景 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 驗證並發邊界。

學習重點

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

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

本模組不處理

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

1.2 select loop 的生命週期設計

Wed, 22 Apr 2026 00:00:00 +0000

select loop 的核心責任是管理長時間 goroutine 的生命週期。它不只是等待多個 channel 的語法，而是決定元件如何接收輸入、處理定時任務、回應取消、釋放資源與停止。

本章目標

學完本章後，你將能夠：

拆解 select loop 中每個 case 的責任
用 ctx.Done() 設計一致的退出路徑
正確建立與停止 ticker
處理 channel 關閉後的 nil channel pattern
測試 worker 在事件、ticker、取消下的行為

【觀察】長期 goroutine 通常同時等待多種訊號

長期 goroutine 的核心特徵是它不只處理一種資料。背景 worker 可能同時等待外部事件、定時掃描、清理工作與停止訊號。

 1func (w Worker) Run(ctx context.Context) error {
 2    statusTicker := time.NewTicker(w.statusInterval)
 3    defer statusTicker.Stop()
 4
 5    cleanupTicker := time.NewTicker(w.cleanupInterval)
 6    defer cleanupTicker.Stop()
 7
 8    for {
 9        select {
10        case <-ctx.Done():
11            return ctx.Err()
12        case event, ok := <-w.events:
13            if !ok {
14                return nil
15            }
16            w.processEvent(ctx, event)
17        case <-statusTicker.C:
18            w.scanStatus(ctx)
19        case <-cleanupTicker.C:
20            w.cleanup(ctx)
21        }
22    }
23}

這個 loop 的責任不是「跑一個無限迴圈」，而是定義 worker 活著時能接受哪些訊號，以及停止時要如何退出。

【判讀】select loop 是元件的生命週期表

select loop 的核心價值是把元件生命週期寫成明確表格。每個 case 都應該能回答：收到什麼訊號、代表什麼意思、下一步做什麼。

case	系統意義	下一步
`ctx.Done()`	上層要求停止	回傳 context error
`w.events`	收到外部事件	套用處理流程
`statusTicker.C`	到時間掃描狀態	執行週期任務
`cleanupTicker.C`	到時間清理暫存資料	回收資源

若某個 case 的意義說不清楚，通常代表 worker 責任太多，或事件來源還沒有被整理成清楚的 channel。

【策略】每個長期 goroutine 先回答四個問題

Select loop 設計的核心檢查是生命週期，而不是語法。寫 loop 前先回答四個問題：

誰能停止它？
它消費哪些輸入？
它擁有哪些資源？
停止時要回報錯誤、靜默退出，還是交給上層判斷？

例如：

1type Worker struct {
2    events          <-chan Event
3    statusInterval  time.Duration
4    cleanupInterval time.Duration
5    processor       Processor
6}

Worker 消費 events，擁有兩個 ticker，停止訊號來自 context.Context。這些資訊應該能從型別與 Run 方法看出來，而不是藏在任意 goroutine 裡。

【執行】ticker 要由使用者停止

Ticker 的核心規則是建立者負責停止。time.NewTicker 會建立 runtime 資源；不再使用時應呼叫 Stop。

 1func (w Worker) Run(ctx context.Context) error {
 2    ticker := time.NewTicker(w.interval)
 3    defer ticker.Stop()
 4
 5    for {
 6        select {
 7        case <-ctx.Done():
 8            return ctx.Err()
 9        case <-ticker.C:
10            if err := w.SyncOnce(ctx); err != nil {
11                return err
12            }
13        }
14    }
15}

Ticker 放在 Run 裡建立，表示它的生命週期和 Run 一致。defer ticker.Stop() 讓 worker 不論因為 context、錯誤或 channel 關閉退出，都能釋放 ticker。

如果 ticker 由外部傳入，外部就應該負責停止。擁有權要一致，否則測試和 shutdown 都會變得模糊。

【執行】處理已關閉 channel 要避免忙等

已關閉 channel 的核心行為是讀取會立即回傳零值與 ok=false。在 select loop 裡，如果不處理這件事，loop 可能一直選到同一個已關閉 channel。

當一個輸入關閉後，還要繼續處理其他輸入，可以把它設成 nil：

 1func (w Worker) Run(ctx context.Context) error {
 2    events := w.events
 3    alerts := w.alerts
 4
 5    for events != nil || alerts != nil {
 6        select {
 7        case <-ctx.Done():
 8            return ctx.Err()
 9        case event, ok := <-events:
10            if !ok {
11                events = nil
12                continue
13            }
14            w.processEvent(ctx, event)
15        case alert, ok := <-alerts:
16            if !ok {
17                alerts = nil
18                continue
19            }
20            w.processAlert(ctx, alert)
21        }
22    }
23
24    return nil
25}

Nil channel 在 select 中永遠不會 ready。這讓 worker 能在某個來源關閉後繼續處理其他來源，而不是忙等或提早退出。

【判讀】default case 會改變 loop 的語意

default 的核心效果是讓 select 不等待。這在非阻塞送出很有用，但在長期 worker 的主 loop 中要小心，因為它可能造成 busy loop。

反模式：

 1for {
 2    select {
 3    case <-ctx.Done():
 4        return
 5    case event := <-events:
 6        process(event)
 7    default:
 8        cleanup()
 9    }
10}

當沒有事件時，這個 loop 會不停執行 cleanup()，可能吃滿 CPU。週期任務應該用 ticker 表達，不應用 default 假裝閒置時執行。

較清楚的做法：

 1cleanupTicker := time.NewTicker(time.Minute)
 2defer cleanupTicker.Stop()
 3
 4for {
 5    select {
 6    case <-ctx.Done():
 7        return
 8    case event := <-events:
 9        process(event)
10    case <-cleanupTicker.C:
11        cleanup()
12    }
13}

Ticker 讓頻率明確，也讓測試可以透過可控時間或手動觸發 channel 驗證行為。

【策略】長工作要移出主要 loop

Select loop 的核心風險是某個 case 裡的工作太久，導致其他訊號無法被處理。若 processEvent 可能執行很久，worker 在這段期間就不會回應 context 或 ticker。

可選策略：

策略	適用情境	代價
case 內同步執行	工作短、需要順序處理	慢事件會阻塞整個 loop
啟動 bounded worker pool	工作可並行、需要限制併發	需要排隊與 shutdown 設計
送入另一個 queue	入口要快速接收	需要 backpressure 策略

長工作需要 bounded worker pool、另一個 queue 或明確的同步策略。無限制地在 case 裡 go process(event) 只會把排隊問題從 channel 轉成 goroutine 堆積，並讓 shutdown 和錯誤回報更難處理。

【測試】把單次工作抽成方法

Select loop 的測試核心是避免所有邏輯都只能透過無限迴圈測。把單次工作抽成 SyncOnce、ProcessOne 或 CleanupOnce，可以讓規則測試和 lifecycle 測試分開。

1func (w Worker) SyncOnce(ctx context.Context) error {
2    return w.processor.Sync(ctx)
3}

Run 只負責排程：

1case <-ticker.C:
2    if err := w.SyncOnce(ctx); err != nil {
3        return err
4    }

單次工作測試：

 1func TestSyncOnceCallsProcessor(t *testing.T) {
 2    processor := &fakeProcessor{}
 3    worker := Worker{processor: processor}
 4
 5    if err := worker.SyncOnce(context.Background()); err != nil {
 6        t.Fatalf("sync once: %v", err)
 7    }
 8    if !processor.called {
 9        t.Fatalf("processor should be called")
10    }
11}

Lifecycle 測試則只確認 context 取消能讓 Run 退出：

 1func TestRunStopsOnContextCancel(t *testing.T) {
 2    ctx, cancel := context.WithCancel(context.Background())
 3    cancel()
 4
 5    worker := Worker{
 6        events:          make(chan Event),
 7        statusInterval:  time.Hour,
 8        cleanupInterval: time.Hour,
 9    }
10
11    if err := worker.Run(ctx); !errors.Is(err, context.Canceled) {
12        t.Fatalf("run error = %v, want context canceled", err)
13    }
14}

這種拆法讓測試不需要等待真實 ticker，也不需要在無限 loop 裡猜時間。

本章不處理

本章先把長生命週期 goroutine 的停止、輸入與排空講清楚；更完整的 worker 協調與平台排程責任，會在下列章節再往外延伸：

和 Go 教材的關係

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

小結

select loop 是長期 goroutine 的生命週期表。好的 loop 會明確處理 context 取消、輸入 channel、ticker、資源釋放與 channel 關閉。避免在主 loop 中濫用 default 或無限制開 goroutine，才能讓服務在高流量、錯誤與 shutdown 情境下保持可預測。

4.2 channel：資料傳遞與 backpressure

Wed, 22 Apr 2026 00:00:00 +0000

channel 是 Go 用來在 goroutine 之間傳遞資料的同步工具。它的核心意義是建立資料流邊界：誰送出資料、誰接收資料、當接收端跟不上時送出端如何被阻擋或丟棄。

本章目標

學完本章後，你將能夠：

建立與使用 channel
看懂 channel 的方向與資料型別
理解 buffered channel 的 backpressure 意義
分辨 blocking send 與 non-blocking send
用 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.3 非阻塞送出與事件丟棄策略

Wed, 22 Apr 2026 00:00:00 +0000

非阻塞送出的核心取捨是用明確降級換取呼叫端可用性。當 channel 滿載時，程式可以等待、回錯、丟棄、覆蓋或轉交可靠儲存；選擇哪一個是服務語意，不是 select 語法偏好。

本章目標

學完本章後，你將能夠：

分辨 blocking send 與 non-blocking send 的服務語意
為 HTTP、worker、即時推送設計不同滿載策略
判斷哪些事件可以丟、哪些不能丟
為 drop 與 queue full 建立 log/metric
測試 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 滿載時要等待、回錯、丟棄、覆蓋或轉交可靠儲存。

事件類型	建議策略	理由
audit log	不應直接丟，應寫可靠儲存或回錯	資料遺失會破壞稽核
UI 即時提示	可丟棄或覆蓋	使用者可重新查詢狀態
狀態轉移事件	通常不應丟	會造成 source of truth 不一致
metrics sample	可取樣或丟棄	趨勢比單筆資料重要
background refresh	可跳過本輪	下次仍可重新計算

這個表格的重點是要求每種事件都要有明確策略。若團隊只說「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 傳遞時，會在下列章節再往外延伸：

和 Go 教材的關係

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

小結

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

4.3 select：同時等待多種事件

Wed, 22 Apr 2026 00:00:00 +0000

select 是 Go 用來同時等待多個 channel 操作的控制結構。它的核心用途是讓一個 goroutine 同時處理資料輸入、取消訊號、timer/ticker 與 fallback 行為。

本章目標

學完本章後，你將能夠：

理解 select 的基本語法
同時等待多個 channel
用 ctx.Done() 停止事件迴圈
用 ticker 建立定時工作
理解 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 可以沿呼叫鏈傳遞。

5.3 race condition 檢查

Wed, 22 Apr 2026 00:00:00 +0000

Race detector 的核心作用是找出測試執行期間發生的 data race。它能指出未同步讀寫同一份記憶體的位置，但不能取代 ownership、mutex、channel 與狀態邊界設計。

本章目標

學完本章後，你將能夠：

分辨 data race 與一般邏輯競爭
用 go test -race ./... 檢查並發路徑
寫出能觸發共享狀態讀寫的測試
依 race report 找到讀寫來源
選擇 mutex、channel owner 或 atomic 修正同步邊界

【觀察】並發 bug 常常不會穩定重現

Data race 的核心問題是測試可能偶爾通過、偶爾失敗，也可能完全不失敗但資料已經不安全。單次執行結果正確，不代表沒有未同步讀寫。

反模式：

1var count int
2
3func increment() {
4    count++
5}

count++ 不是原子操作。它包含讀取、加一、寫回。多個 goroutine 同時執行時，可能互相覆蓋結果，也可能被 race detector 偵測到未同步讀寫。

【判讀】data race 是未同步的並發讀寫

Data race 的核心定義是至少兩個 goroutine 同時存取同一份記憶體，其中至少一個是寫入，而且沒有同步保護。

觸發測試：

 1func TestIncrementRace(t *testing.T) {
 2    var wg sync.WaitGroup
 3
 4    for i := 0; i < 100; i++ {
 5        wg.Add(1)
 6        go func() {
 7            defer wg.Done()
 8            increment()
 9        }()
10    }
11
12    wg.Wait()
13}

一般 go test 不一定會失敗。go test -race 會在 runtime 偵測這類未同步讀寫，並輸出讀取與寫入發生的位置。

【執行】用 go test -race 跑到相關路徑

Race detector 的核心限制是只能檢查實際執行到的程式路徑。沒有被測試覆蓋的 goroutine、handler、repository 或 broadcast path，不會被它發現。

1go test -race ./...

這個指令會用 race detector 跑所有 package 的測試。它會比一般測試慢，但對含有 goroutine、共享 map、WebSocket hub、background worker 的服務非常重要。

若專案很大，可以先針對相關 package：

1go test -race ./internal/websocket ./internal/storage ./internal/worker

範圍縮小能讓日常執行更快，但合併前仍應跑完整路徑。

【策略】併發測試要讓共享狀態真的被同時讀寫

Race detector 的核心前提是測試要製造相關路徑。只建立 repository 卻不並發讀寫，race detector 沒有機會回報。

 1func TestRepositoryConcurrentAccess(t *testing.T) {
 2    repo := NewUserRepository()
 3    ctx := context.Background()
 4
 5    var wg sync.WaitGroup
 6    for i := 0; i < 100; i++ {
 7        i := i
 8        wg.Add(1)
 9        go func() {
10            defer wg.Done()
11            id := fmt.Sprintf("user_%d", i)
12            _ = repo.Save(ctx, User{ID: id})
13            _, _, _ = repo.Find(ctx, id)
14        }()
15    }
16
17    wg.Wait()
18}

這個測試的主要斷言在「讓 race detector 執行共享 map 的讀寫路徑」。若 repository 忘記加 lock，-race 會指出問題。

【執行】WebSocket hub 也需要 race path

WebSocket hub 的核心並發風險是 client 註冊、取消註冊、訂閱變更與 broadcast 可能同時發生。測試應讓這些路徑交錯執行。

 1func TestHubConcurrentBroadcastAndUnregister(t *testing.T) {
 2    hub := NewHub()
 3    clients := make([]*Client, 0, 100)
 4
 5    for i := 0; i < 100; i++ {
 6        client := NewTestClient(fmt.Sprintf("client_%d", i), 8)
 7        client.Subscribe("alerts")
 8        hub.clients[client] = struct{}{}
 9        clients = append(clients, client)
10    }
11
12    var wg sync.WaitGroup
13    wg.Add(2)
14
15    go func() {
16        defer wg.Done()
17        for i := 0; i < 100; i++ {
18            hub.Broadcast("alerts", ServerMessage{Type: "notification"})
19        }
20    }()
21
22    go func() {
23        defer wg.Done()
24        for _, client := range clients {
25            hub.unregisterClient(client)
26        }
27    }()
28
29    wg.Wait()
30}

這個測試是否需要 lock，取決於 hub 的設計。如果 hub 保證所有操作都在單一 event loop 中執行，測試就應該透過 channel 操作，而不是直接呼叫未同步方法。測試要符合 ownership 設計，不應製造不被 API 允許的並發。

【判讀】race report 要看讀寫兩端

Race report 的核心資訊是兩個位置：一端讀或寫，另一端寫。修正時不要只看最後一行，要找出是哪個共享資料缺少同步。

典型報告會包含：

1WARNING: DATA RACE
2Read at 0x...
3  example.com/app.(*UserRepository).Find()
4
5Previous write at 0x...
6  example.com/app.(*UserRepository).Save()

這表示 Find 和 Save 同時碰到同一份資料，且缺少同步。修正方向是在 repository owner 補上 mutex、channel ownership 或其他同步邊界。

【策略】修正方式要對應狀態形狀

修正 data race 的核心選擇是建立正確同步邊界。常見方法有 mutex、channel owner、atomic。

方法	適用情境	注意事項
mutex	多方法讀寫同一份 map/slice/state	lock 要保護完整不變式
channel owner	狀態修改可集中成事件 loop	要設計 reply、shutdown、backpressure
atomic	單一數值 counter 或 flag	不適合複雜狀態

Mutex 範例：

 1type Counter struct {
 2    mu    sync.Mutex
 3    value int
 4}
 5
 6func (c *Counter) Inc() {
 7    c.mu.Lock()
 8    defer c.mu.Unlock()
 9    c.value++
10}
11
12func (c *Counter) Value() int {
13    c.mu.Lock()
14    defer c.mu.Unlock()
15    return c.value
16}

鎖應該屬於擁有狀態的型別，並保護一個清楚的不變條件。只為了讓 race detector 安靜而到處加鎖，會讓 ownership 分散，後續仍然難以判斷資料一致性。

【判讀】race-free 不代表行為正確

Race detector 的核心邊界是它只找 data race，不保證並發邏輯正確。沒有 data race 的程式仍可能 deadlock、漏訊息、順序錯誤、重複 close 或違反資料語意。

例如：

1select {
2case client.send <- message:
3default:
4    // drop
5}

這段程式可能沒有 data race，但「queue full 時丟訊息」是否正確是服務語意問題。Race detector 不會告訴你該丟、該斷線、還是該寫可靠 queue。

因此並發測試要分成兩層：

用 go test -race 找未同步記憶體存取。
用行為測試檢查 channel close、queue full、context cancel、cleanup、timeout。

【測試】把 race check 納入固定流程

Race check 的核心價值來自重複執行。只在出事後手動跑，效果有限。

建議流程：

1go test ./...
2go test -race ./...

日常開發可以先跑相關 package，提交前或 CI 跑完整 race suite。若 race suite 太慢，至少讓含有 hub、repository、worker、client state 的 package 固定跑 -race。

本章不處理

本章先處理共享 state、channel ownership 與 goroutine lifecycle 的 race 風險；lock-free 與完整 memory model，會在下列章節再往外延伸：

和 Go 教材的關係

這一章承接的是共享狀態、channel ownership 與 lifecycle；如果你要先回看語言教材，可以讀：

小結

go test -race 是 Go 並發服務的基本安全網，但它只檢查測試執行到的 data race。你仍然需要設計清楚的 state owner、lock boundary、channel ownership 與行為測試。Race-free 不是正確性的全部；它只是可靠性的第一層檢查。

1.4 共享狀態與複製邊界

Wed, 22 Apr 2026 00:00:00 +0000

共享狀態的核心規則是同一份可變資料若會被多個 goroutine 存取，就必須有明確 owner 與保護邊界。Map 需要同步，slice 回傳前通常要 copy，可變指標不能隨意暴露，修改行為應集中在擁有狀態的型別內。

本章目標

學完本章後，你將能夠：

判斷哪個型別擁有共享狀態
用 sync.RWMutex 保護 map 與 slice
避免回傳內部 map、slice、pointer
分辨 shallow copy 與 deep copy 的邊界
用測試與 race detector 驗證共享狀態安全性

【觀察】共享狀態風險通常延遲出現

共享狀態的核心風險是錯誤可能只在特定併發時序下出現。單元測試可能通過，本地手動操作也正常，但高流量下會出現 data race、map panic、狀態被外部修改或歷史資料被覆蓋。

反模式示意：

 1type Store struct {
 2    users map[string]User
 3}
 4
 5func (s *Store) Save(user User) {
 6    s.users[user.ID] = user
 7}
 8
 9func (s *Store) Users() map[string]User {
10    return s.users
11}

這個型別有兩個問題：map 沒有同步保護，且 Users 直接暴露內部 map。呼叫端拿到 map 後可以繞過 Store 修改資料。

【判讀】mutex 保護的是狀態不變式

Mutex 的核心責任不是讓程式「不會同時跑」，而是保護某一組資料的不變式。只要讀寫同一份可變資料，就應該由同一個 owner 控制 lock。

 1type UserRepository struct {
 2    mu    sync.RWMutex
 3    users map[string]User
 4}
 5
 6func NewUserRepository() *UserRepository {
 7    return &UserRepository{
 8        users: make(map[string]User),
 9    }
10}

UserRepository 是 users map 的 owner。外部程式不應持有 users 的 reference，也不應知道它用 map、資料庫或其他結構保存。

【執行】所有讀寫都經過 owner method

共享 map 的核心規則是所有讀寫都經過同一組方法。寫入使用 Lock，讀取使用 RLock。

 1func (r *UserRepository) Save(ctx context.Context, user User) error {
 2    r.mu.Lock()
 3    defer r.mu.Unlock()
 4
 5    r.users[user.ID] = user
 6    return nil
 7}
 8
 9func (r *UserRepository) Find(ctx context.Context, id string) (User, bool, error) {
10    r.mu.RLock()
11    defer r.mu.RUnlock()
12
13    user, ok := r.users[id]
14    return user, ok, nil
15}

context.Context 在 memory repository 裡可能用不到，但保留在 method signature 可以讓未來改成資料庫或遠端儲存時支援取消。這是 repository port 常見的演進邊界。

【判讀】回傳內部 map 會破壞 lock

回傳 map 的核心風險是鎖只保護到方法結束。方法回傳後，呼叫端拿到的仍然是同一份 map，任何修改都會繞過 owner。

反模式：

1func (r *UserRepository) UnsafeUsers(ctx context.Context) map[string]User {
2    r.mu.RLock()
3    defer r.mu.RUnlock()
4
5    return r.users
6}

這段程式看起來有加鎖，但鎖釋放後外部仍能修改內部 map：

1users := repo.UnsafeUsers(ctx)
2delete(users, "user_1")

安全做法是回傳 copy：

 1func (r *UserRepository) Users(ctx context.Context) (map[string]User, error) {
 2    r.mu.RLock()
 3    defer r.mu.RUnlock()
 4
 5    result := make(map[string]User, len(r.users))
 6    for id, user := range r.users {
 7        result[id] = user
 8    }
 9    return result, nil
10}

呼叫端可以自由修改 result，不會影響 repository 內部狀態。

【判讀】slice copy 保護的是底層 array

Slice 的核心風險是 slice header 會被複製，但底層 array 可能共享。直接回傳 slice 會讓呼叫端修改 owner 的內部資料。

 1type RecentEvents struct {
 2    mu     sync.RWMutex
 3    events []Event
 4}
 5
 6func (r *RecentEvents) Append(ctx context.Context, event Event) {
 7    r.mu.Lock()
 8    defer r.mu.Unlock()
 9
10    r.events = append(r.events, event)
11}

安全的 list method：

1func (r *RecentEvents) List(ctx context.Context) []Event {
2    r.mu.RLock()
3    defer r.mu.RUnlock()
4
5    result := make([]Event, len(r.events))
6    copy(result, r.events)
7    return result
8}

copy 建立新的底層 array。呼叫端對 result 排序、截斷、append 或修改元素，不會改到 r.events。

【策略】值型別可以 shallow copy，可變欄位需要 deep copy

Copy boundary 的核心判斷是資料裡是否還包含可變 reference。若 struct 只有 string、int、time.Time 這類值型別，shallow copy 通常足夠；若 struct 包含 map、slice 或 pointer，就要考慮 deep copy。

值型別範例：

1type Event struct {
2    ID        string
3    Type      string
4    CreatedAt time.Time
5}

這種 Event 放在 slice 裡，用 copy 複製 slice 通常足夠。

含可變欄位的範例：

1type Event struct {
2    ID       string
3    Type     string
4    Metadata map[string]string
5}

這時只 copy slice 不夠，因為每個 Event.Metadata 仍然指向同一份 map。需要 clone：

 1func CloneEvent(event Event) Event {
 2    cloned := event
 3    if event.Metadata != nil {
 4        cloned.Metadata = make(map[string]string, len(event.Metadata))
 5        for key, value := range event.Metadata {
 6            cloned.Metadata[key] = value
 7        }
 8    }
 9    return cloned
10}

是否需要 deep copy 取決於 API 承諾。如果呼叫端不應修改 repository 內部資料，就要複製所有可變 reference。

【判讀】回傳 pointer 要代表明確修改權

Pointer 回傳的核心語意是呼叫端取得同一份資料的參照。若資料屬於共享狀態，回傳 pointer 通常會破壞 owner 邊界。

容易誤解的 API：

 1func (r *UserRepository) FindPointer(ctx context.Context, id string) (*User, bool) {
 2    r.mu.RLock()
 3    defer r.mu.RUnlock()
 4
 5    user, ok := r.users[id]
 6    if !ok {
 7        return nil, false
 8    }
 9    return &user, true
10}

這段程式回傳的是區域變數 user 的指標，不是 map 內部資料的可修改入口。呼叫端修改這個 pointer，不會保存回 repository。API 看起來像能修改，實際不能，語意不清楚。

更清楚的做法是回傳 value，並提供明確 update method：

 1func (r *UserRepository) UpdateEmail(ctx context.Context, id string, email string) (bool, error) {
 2    r.mu.Lock()
 3    defer r.mu.Unlock()
 4
 5    user, ok := r.users[id]
 6    if !ok {
 7        return false, nil
 8    }
 9
10    user.Email = email
11    r.users[id] = user
12    return true, nil
13}

修改行為集中在 repository 內，lock、驗證與狀態一致性也留在同一個地方。

【策略】mutex 和 channel owner 要按資料形狀選擇

狀態保護的核心選擇是 mutex owner 或 goroutine owner。兩者都符合 Go 的精神，差異在資料存取模式。

方法	適用情境	代價
mutex owner	多個方法需要同步讀寫狀態	要維護 lock 與 copy boundary
goroutine owner	所有修改都能表示成訊息	要設計 command、reply、shutdown

Mutex 版本：

1repo.Save(ctx, user)
2user, ok, err := repo.Find(ctx, id)

Goroutine owner 版本：

1type command struct {
2    kind  string
3    user  User
4    reply chan result
5}

不要為了避免 mutex 而把簡單狀態硬改成複雜訊息系統。也不要在需要嚴格順序與單一事件流時到處加 lock。選擇應該來自資料形狀與讀寫模式。

【測試】copy boundary 要用外部修改驗證

Copy boundary 的測試核心是呼叫 getter 後修改回傳值，再確認 owner 內部資料沒有被改動。

 1func TestUsersReturnsCopy(t *testing.T) {
 2    repo := NewUserRepository()
 3    ctx := context.Background()
 4
 5    if err := repo.Save(ctx, User{ID: "user_1", Email: "a@example.com"}); err != nil {
 6        t.Fatalf("save user: %v", err)
 7    }
 8
 9    users, err := repo.Users(ctx)
10    if err != nil {
11        t.Fatalf("users: %v", err)
12    }
13    delete(users, "user_1")
14
15    _, ok, err := repo.Find(ctx, "user_1")
16    if err != nil {
17        t.Fatalf("find user: %v", err)
18    }
19    if !ok {
20        t.Fatalf("repository should not be modified through returned map")
21    }
22}

Slice copy 也用同樣方式測：

 1func TestEventListReturnsCopy(t *testing.T) {
 2    events := &RecentEvents{}
 3    ctx := context.Background()
 4
 5    events.Append(ctx, Event{ID: "evt_1"})
 6    got := events.List(ctx)
 7    got[0].ID = "changed"
 8
 9    again := events.List(ctx)
10    if again[0].ID != "evt_1" {
11        t.Fatalf("internal event was modified through returned slice")
12    }
13}

這類測試能直接防止未來有人為了「省 copy」而破壞狀態邊界。

【測試】race detector 驗證同步邊界

Race detector 的核心用途是找出未同步的共享記憶體存取。對含有 goroutine、map、slice、repository 的測試，應定期執行：

1go test -race ./...

可以用併發測試增加觸發機率：

 1func TestRepositoryConcurrentAccess(t *testing.T) {
 2    repo := NewUserRepository()
 3    ctx := context.Background()
 4
 5    var wg sync.WaitGroup
 6    for i := 0; i < 100; i++ {
 7        i := i
 8        wg.Add(1)
 9        go func() {
10            defer wg.Done()
11            id := fmt.Sprintf("user_%d", i)
12            _ = repo.Save(ctx, User{ID: id})
13            _, _, _ = repo.Find(ctx, id)
14        }()
15    }
16    wg.Wait()
17}

這個測試本身不一定能證明沒有所有問題，但搭配 -race 可以檢查 repository 方法是否真的包住共享 map。

本章不處理

本章先聚焦單一 Go process 內的共享狀態保護；更外層的資料庫交易、快取一致性與資料複製邊界，會在下列章節再往外延伸：

和 Go 教材的關係

這一章承接的是 repository、copy boundary 與 state owner；如果你要先回看語言教材，可以讀：

小結

共享狀態的安全邊界由 owner、lock、copy 與明確修改方法組成。Map/slice 讀寫要經過同一個 owner；getter 不應暴露內部可變資料；含 map、slice、pointer 的 struct 要考慮 deep copy；修改行為應集中在方法內。這些規則能讓長時間運行的 Go 服務避開 data race、外部突變與難以重現的狀態錯誤。

4.4 sync.RWMutex：保護共享狀態

Wed, 22 Apr 2026 00:00:00 +0000

sync.RWMutex 是 Go 用來保護共享狀態的讀寫鎖。它的核心用途是允許多個讀取者同時讀取，但寫入者必須獨占資料，避免 goroutine 同時讀寫 map、slice 或 struct 時產生資料競爭。

本章目標

學完本章後，你將能夠：

理解 data race 的風險
區分 Mutex 與 RWMutex
用 RLock / RUnlock 保護讀取
用 Lock / Unlock 保護寫入
避免回傳內部 map 或 slice 破壞鎖邊界

【觀察】共享 map 不能被多個 goroutine 無保護地讀寫

共享狀態的核心規則是：只要多個 goroutine 可能同時讀寫同一份資料，就必須用同步機制保護。以下程式同時讀寫 map，存在 data race：

 1type UserRepository struct {
 2    users map[string]User
 3}
 4
 5func (r *UserRepository) Set(id string, user User) {
 6    r.users[id] = user
 7}
 8
 9func (r *UserRepository) Get(id string) (User, bool) {
10    user, ok := r.users[id]
11    return user, ok
12}

如果 Set 和 Get 從不同 goroutine 同時執行，map 可能被同時讀寫。Go 的 map 不保證這種情境安全。

【判讀】RWMutex 區分讀取與寫入

RWMutex 的核心規則是：讀取使用 RLock，寫入使用 Lock；多個讀取可並行，寫入會排他。

 1type UserRepository struct {
 2    users map[string]User
 3    mu    sync.RWMutex
 4}
 5
 6func (r *UserRepository) Set(id string, user User) {
 7    r.mu.Lock()
 8    defer r.mu.Unlock()
 9    r.users[id] = user
10}
11
12func (r *UserRepository) Get(id string) (User, bool) {
13    r.mu.RLock()
14    defer r.mu.RUnlock()
15    user, ok := r.users[id]
16    return user, ok
17}

Set 修改 map，所以用 Lock。Get 只讀 map，所以用 RLock。

【策略】鎖保護的是資料不變式

鎖範圍的核心規則是：鎖要包住所有需要一致觀察或一致修改的資料。鎖的邊界應涵蓋完整不變式，慢速 I/O、網路呼叫與和共享資料無關的計算則應放在鎖外。

例如，這個更新同時修改兩個欄位，兩個欄位要在同一把鎖內更新：

1func (r *UserRepository) Add(user User) {
2    r.mu.Lock()
3    defer r.mu.Unlock()
4
5    r.users[user.ID] = user
6    r.count++
7}

如果 users 和 count 分開鎖，讀者可能看到 map 已更新但 count 還沒更新的中間狀態。

【執行】回傳資料時要保留 copy boundary

鎖邊界的核心規則是：鎖只能保護鎖內操作；回傳內部 map 會讓呼叫者在鎖外修改資料，破壞 repository 對狀態的控制權。

不安全做法：

1func (r *UserRepository) Users() map[string]User {
2    r.mu.RLock()
3    defer r.mu.RUnlock()
4    return r.users
5}

安全做法是回傳複製：

 1func (r *UserRepository) Users() map[string]User {
 2    r.mu.RLock()
 3    defer r.mu.RUnlock()
 4
 5    result := make(map[string]User, len(r.users))
 6    for id, user := range r.users {
 7        result[id] = user
 8    }
 9    return result
10}

呼叫者拿到的是複本，不能繞過 UserRepository 修改內部狀態。

Mutex 還是 RWMutex？

選擇鎖的核心規則是：讀多寫少且讀操作可並行時用 RWMutex；不確定時先用 Mutex，設計更簡單。

鎖	適合情境
`sync.Mutex`	狀態小、讀寫都簡單、沒有明顯讀多寫少
`sync.RWMutex`	讀取頻繁、寫入較少、讀操作可安全並行

sync.Mutex 的核心優勢是簡單。若狀態很小、讀寫都很快，或讀寫比例尚未明確，先使用 Mutex 通常更容易維護。它讓每次存取都走同一條鎖路徑，讀者也比較容易確認資料何時被保護。

sync.RWMutex 的核心優勢是讀多寫少時可以讓多個讀取並行。它適合像 in-memory cache、狀態查詢 repository 或連線註冊表這類讀取頻繁的資料結構。使用它時，寫入仍然要用 Lock，因為 RLock 只適合保護純讀取。

鎖選擇的判斷重點是資料不變式與讀寫比例。若讀取本身會組裝複雜資料、需要複製大型 map，或很快就會呼叫外部 I/O，RWMutex 帶來的並行讀取收益可能被複雜度抵消。

替代方案：什麼時候不用 RWMutex

RWMutex 不是共享狀態保護的唯一選擇。三類替代方案各有適用條件：

方案	適用情境	跟 RWMutex 對比
`sync.Map`	key 集合大、entries 異步增減、讀寫分散在不同 key	內建讀寫並行、無全域鎖；但語意不同（無 size、無 range 一致性）
`sync/atomic`	單一純量（counter、flag、pointer）	無鎖、最快；但只能保護單一值、不能保護結構不變式
Channel-based coordination	狀態由單一 owner goroutine 持有、其他 goroutine 透過 channel 傳訊息	用 ownership 取代 sharing；適合 producer / consumer pattern、見 4.2 channel

判別準則：

保護多欄位不變式（如 users + count 同步）→ RWMutex 或 Mutex
保護單一純量且操作可表達為 atomic op（CAS、increment）→ sync/atomic
保護大量獨立 key 且無跨 key 不變式 → sync.Map
狀態可由單一 owner 持有、外部用訊息驅動 → channel-based、見 4.2 / 4.5 backpressure

選錯方案的代價：用 sync/atomic 保護需要不變式的多欄位 → silent atomicity violation；用 sync.Map 期待 range 一致性 → 拿到 inconsistent snapshot；用 channel 處理需要嚴格 ordering 的 fan-in → 順序錯亂。

RWMutex 不解的問題

RWMutex 解的是 data race（多 goroutine 同時讀寫同一份資料的 visible race）。下列問題不在 RWMutex 防護範圍、必須由其他機制處理：

不防的問題	為什麼不解	該用什麼
Deadlock	多把鎖的鎖順序不一致、`RWMutex` 沒有偵測能力	鎖排序協議、`go test -race` 並非 deadlock detector
Starvation	RWMutex 設計上 reader 多時 writer 可能長期等不到（Go 實作有部分 fairness 保護）	量測 lock 等待時間、讀多時切 channel-based 或 sharded 鎖
Lock contention scaling	goroutine 增多時、單把鎖的競爭成本可能 dominate；`RWMutex` 多核 scalability 弱	sharded lock、sync.Map、無鎖結構
Context cancellation	reader 已經 hold RLock 時、context 取消不會強制釋放；reader 必須主動 check ctx	lock 內快進快出、長操作放鎖外、check ctx
Atomicity violation	把多步操作拆到多次 Lock/Unlock 中間、其他 goroutine 可能看到中間狀態	拉大鎖範圍、或改 transaction-like API
Memory ordering（跨鎖）	RWMutex 只保證鎖內 happens-before、跨鎖讀寫的 ordering 沒保證	用 channel 傳遞 ordering、或 atomic load/store

判讀訊號：

go test -race pass、production 仍偶發資料異常 → 可能 atomicity violation 或 ordering bug、不是 data race
多核 CPU 加倍但 throughput 不增 → lock contention dominate、考慮 shard
p99 latency 在高 concurrency 下爆炸 → reader 排隊或 starvation、查 lock 等待 metric
shutdown 時 goroutine 不退 → reader hold RLock + 未 check ctx、補 context 檢查

Context dependence：scale 改變策略

RWMutex 的有效性會隨 deployment 條件變化：

Map 大小：copy 成本隨 entries 線性增長、1k entries 廉價、1M entries 每次 copy 都是 GC pressure 來源；大 map 改 sync.Map 或 sharded
讀寫比例：90% 讀以下、RWMutex 收益不顯著、Mutex 簡單；讀寫接近時 RWMutex 的內部 atomic 操作成本可能反而比 Mutex 慢
Goroutine 數量：少（< 10）時 contention 微、多（> 1000）時 RWMutex 不適合、要 shard 或換 lock-free 結構
持鎖時間：鎖內 microsecond 級 OK、毫秒級會堆隊；鎖內絕不做 I/O / 網路呼叫

選擇 RWMutex 前先問四件事

RWMutex 只解 data race subset——不解 deadlock / starvation / atomicity violation / context cancellation / 多核 contention scaling。狀態可表達為 atomic op、單 owner channel、或大量獨立 key 時、sync/atomic / channel-based / sync.Map 通常更合適。選擇前先問：「不變式跨幾個欄位？讀寫比例？goroutine 數量？持鎖時間？」

6.4 如何新增背景工作流程

Wed, 22 Apr 2026 00:00:00 +0000

新增背景工作流程的核心規則是先定義生命週期，再定義資料流。worker 是有 context、輸入、輸出、錯誤處理與 shutdown 協定的長期元件。

本章目標

學完本章後，你將能夠：

判斷一段工作是否適合做成 worker
用 Run(ctx) 設計 worker 生命週期
用 channel 和 ticker 表達資料流與週期性工作
處理 queue full、shutdown 與錯誤記錄
分開測試 SyncOnce、Run(ctx) 與 channel 行為

【觀察】worker 是有生命週期的元件

worker 的核心定義是長時間運行、可被啟動、可被取消、會消費輸入或定期執行工作的元件。任意程式碼包進 go func() 只能產生背景 goroutine，還需要生命週期協定才會成為可維護的 worker。

適合做成 worker 的工作通常有三種：

工作類型	範例	worker 責任
queue consumer	從 channel 讀取外部事件	驗證、轉送 processor
periodic task	每 30 秒同步一次外部狀態	產生 command 或 event
cleanup task	定期清理過期資料	呼叫 repository 或 usecase 的清理方法

本章使用「通知同步 worker」作為範例。它定期向外部來源取得通知更新，轉成 domain event，再交給 EventProcessor 處理。

【判讀】worker 責任要先寫清楚

worker 責任的核心問題是它消費什麼、產生什麼、交給誰處理。worker 應聚焦在資料取得、格式轉換與轉交處理器，業務規則、狀態更新與 client 推送要留給對應的 usecase 或 processor。

先定義外部來源：

 1type NotificationSource interface {
 2    FetchUpdates(ctx context.Context) ([]RawNotificationUpdate, error)
 3}
 4
 5type RawNotificationUpdate struct {
 6    ID             string
 7    NotificationID string
 8    Topic          string
 9    Title          string
10    OccurredAt     time.Time
11}

再定義 worker 會呼叫的處理器：

1type EventProcessor interface {
2    Process(ctx context.Context, event DomainEvent) error
3}

worker 的責任是把外部更新取回來、normalize 成 DomainEvent、交給 processor。repository 寫入與推送規則仍然留在 processor 或 usecase 裡。

【策略】把單次工作獨立成 `SyncOnce`

worker 的核心設計技巧是把「單次工作」和「長時間迴圈」分開。SyncOnce 負責做一次同步，Run(ctx) 負責週期性呼叫它。

 1type SyncWorker struct {
 2    source    NotificationSource
 3    processor EventProcessor
 4    logger    *slog.Logger
 5}
 6
 7func NewSyncWorker(source NotificationSource, processor EventProcessor, logger *slog.Logger) *SyncWorker {
 8    return &SyncWorker{
 9        source:    source,
10        processor: processor,
11        logger:    logger,
12    }
13}

SyncOnce 可以像普通函式一樣測試：

 1func (w *SyncWorker) SyncOnce(ctx context.Context) error {
 2    updates, err := w.source.FetchUpdates(ctx)
 3    if err != nil {
 4        return fmt.Errorf("fetch notification updates: %w", err)
 5    }
 6
 7    for _, update := range updates {
 8        event, err := NormalizeNotificationUpdate(update, time.Now())
 9        if err != nil {
10            w.logger.Warn("skip invalid notification update", "id", update.ID, "error", err)
11            continue
12        }
13
14        if err := w.processor.Process(ctx, event); err != nil {
15            return fmt.Errorf("process notification update %s: %w", update.ID, err)
16        }
17    }
18
19    return nil
20}

這裡的 time.Now() 先展示基本寫法；如果測試需要固定時間，可以把 clock 注入進 worker。時間注入會在後面測試章節更完整處理。

【執行】`Run(ctx)` 管理長時間生命週期

Run(ctx) 的核心責任是等待 ticker、呼叫單次工作、尊重取消訊號。它應該在 context 被取消時退出，並釋放 ticker。

 1func (w *SyncWorker) Run(ctx context.Context, interval time.Duration) error {
 2    ticker := time.NewTicker(interval)
 3    defer ticker.Stop()
 4
 5    for {
 6        select {
 7        case <-ctx.Done():
 8            return ctx.Err()
 9        case <-ticker.C:
10            if err := w.SyncOnce(ctx); err != nil {
11                w.logger.Error("sync worker failed", "error", err)
12            }
13        }
14    }
15}

這個版本把單次同步錯誤記錄下來，但不讓 worker 退出。這是策略選擇：若外部來源短暫失敗，worker 可以等待下一輪；若錯誤代表設定失效或授權失效，則可以選擇 return error 讓上層重啟或停止服務。

worker 錯誤策略應該明確。暫時性錯誤通常要記錄後等待下一輪；致命設定錯誤則可以回傳給上層，讓服務決定重啟或停止。

【判讀】channel worker 要設計 backpressure

channel worker 的核心問題是接收端跟不上時要怎麼辦。buffer 大小、blocking send、non-blocking send 都是在回答 backpressure 策略。

假設外部 HTTP callback 會把 raw update 送進 worker queue：

 1type QueueWorker struct {
 2    updates   chan RawNotificationUpdate
 3    processor EventProcessor
 4    logger    *slog.Logger
 5}
 6
 7func NewQueueWorker(processor EventProcessor, logger *slog.Logger, bufferSize int) *QueueWorker {
 8    return &QueueWorker{
 9        updates:   make(chan RawNotificationUpdate, bufferSize),
10        processor: processor,
11        logger:    logger,
12    }
13}

送入 queue 可以選擇 blocking 或 non-blocking。若呼叫端不能被背景處理拖慢，可以用 non-blocking send 並回傳錯誤：

 1var ErrQueueFull = errors.New("notification update queue full")
 2
 3func (w *QueueWorker) Enqueue(update RawNotificationUpdate) error {
 4    select {
 5    case w.updates <- update:
 6        return nil
 7    default:
 8        return ErrQueueFull
 9    }
10}

這個設計很誠實：queue 滿了就是系統忙碌。上層可以記錄 log、回 503，或告訴 client 稍後重試。

【執行】queue worker 要同時監聽輸入與取消

queue worker 的核心生命週期是等待 update 或 context cancel。Run(ctx) 裡應用 select 同時處理這兩件事。

 1func (w *QueueWorker) Run(ctx context.Context) error {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            return ctx.Err()
 6        case update, ok := <-w.updates:
 7            if !ok {
 8                return nil
 9            }
10            if err := w.handleUpdate(ctx, update); err != nil {
11                w.logger.Error("handle notification update failed", "id", update.ID, "error", err)
12            }
13        }
14    }
15}

handleUpdate 負責單筆資料轉換與處理：

1func (w *QueueWorker) handleUpdate(ctx context.Context, update RawNotificationUpdate) error {
2    event, err := NormalizeNotificationUpdate(update, time.Now())
3    if err != nil {
4        return fmt.Errorf("normalize update: %w", err)
5    }
6    return w.processor.Process(ctx, event)
7}

這裡仍然遵守同一條邊界：worker 不直接改 repository，只把事件交給 processor。

【策略】shutdown 是否 drain queue 要先決定

shutdown 的核心決策是取消時要立刻停止，還是處理完 queue 中既有資料。兩種策略都合理，但語意不同。

策略	做法	適用情境
立即停止	收到 `ctx.Done()` 就 return	即時通知、可重試資料
drain queue	停止接收新資料，處理已排隊資料	不可輕易丟棄的資料

立即停止比較簡單：

1case <-ctx.Done():
2    return ctx.Err()

drain queue 則需要另一個停止接收的協定，例如由擁有送出端的一方關閉 channel，再讓 worker range 到 channel 關閉。channel close 的所有權要留在送出端，因為送出端最清楚是否還會送資料。

這裡的核心區分是「取消 context」和「關閉 channel」代表不同訊號。context 表示這件工作該停了；channel close 表示不會再有新資料。兩者可以搭配，但語意不同。

【判讀】worker 使用服務生命週期 context

worker context 的核心規則是：長時間 worker 使用服務生命週期 context，單次工作可以另外接收 request context。某個 HTTP request 的 context 只適合控制該次請求；request 結束後 context 會被取消。

1func (w *QueueWorker) Enqueue(update RawNotificationUpdate) error {
2    select {
3    case w.updates <- update:
4        return nil
5    default:
6        return ErrQueueFull
7    }
8}

Enqueue 不把 request context 存起來。真正處理 update 時，worker 使用自己的 Run(ctx) context 控制生命週期。

若某筆 update 需要保留 request ID 或 correlation ID，應把它放進明確欄位，而不是依賴 context value 在背景工作中長期存在。

【執行】`SyncOnce` 測試要隔離時間與外部來源

SyncOnce 測試的核心目標是確認單次工作會把外部資料交給 processor。測試重點放在單次同步，不需要等待真實 ticker。

 1type fakeNotificationSource struct {
 2    updates []RawNotificationUpdate
 3    err     error
 4}
 5
 6func (f fakeNotificationSource) FetchUpdates(ctx context.Context) ([]RawNotificationUpdate, error) {
 7    if f.err != nil {
 8        return nil, f.err
 9    }
10    return f.updates, nil
11}
12
13type recordingProcessor struct {
14    events []DomainEvent
15}
16
17func (p *recordingProcessor) Process(ctx context.Context, event DomainEvent) error {
18    p.events = append(p.events, event)
19    return nil
20}

測試單次同步：

 1func TestSyncWorkerSyncOnce(t *testing.T) {
 2    source := fakeNotificationSource{
 3        updates: []RawNotificationUpdate{
 4            {
 5                ID:             "evt_1",
 6                NotificationID: "ntf_1",
 7                Topic:          "deployments",
 8                Title:          "Deploy finished",
 9                OccurredAt:     time.Date(2026, 4, 22, 10, 0, 0, 0, time.UTC),
10            },
11        },
12    }
13    processor := &recordingProcessor{}
14    worker := NewSyncWorker(source, processor, slog.Default())
15
16    if err := worker.SyncOnce(context.Background()); err != nil {
17        t.Fatalf("sync once: %v", err)
18    }
19
20    if len(processor.events) != 1 {
21        t.Fatalf("processed events = %d, want 1", len(processor.events))
22    }
23}

這個測試不需要 goroutine。先把單次工作測清楚，再測長時間生命週期。

【執行】`Run(ctx)` 測試要能快速取消

Run(ctx) 測試的核心目標是確認 worker 會尊重取消訊號。測試應該使用已取消或很短的 context，讓測試快速結束。

 1func TestSyncWorkerRunStopsWhenContextCanceled(t *testing.T) {
 2    source := fakeNotificationSource{}
 3    processor := &recordingProcessor{}
 4    worker := NewSyncWorker(source, processor, slog.Default())
 5
 6    ctx, cancel := context.WithCancel(context.Background())
 7    cancel()
 8
 9    err := worker.Run(ctx, time.Hour)
10    if !errors.Is(err, context.Canceled) {
11        t.Fatalf("error = %v, want context.Canceled", err)
12    }
13}

這個測試用 time.Hour 當 interval，因為 context 已經取消，Run 應該立刻退出，不需要等 ticker。

【執行】queue full 測試要固定 buffer

queue full 測試的核心目標是確認 backpressure 策略。buffer 設成 1，先塞滿，再確認第二次 enqueue 回錯。

 1func TestQueueWorkerEnqueueFull(t *testing.T) {
 2    worker := NewQueueWorker(&recordingProcessor{}, slog.Default(), 1)
 3
 4    err := worker.Enqueue(RawNotificationUpdate{ID: "evt_1"})
 5    if err != nil {
 6        t.Fatalf("first enqueue: %v", err)
 7    }
 8
 9    err = worker.Enqueue(RawNotificationUpdate{ID: "evt_2"})
10    if !errors.Is(err, ErrQueueFull) {
11        t.Fatalf("error = %v, want ErrQueueFull", err)
12    }
13}

這個測試不啟動 worker，所以 channel 裡第一筆資料不會被消費，第二筆必然遇到 full。這比用 sleep 製造滿載狀態穩定。

實作檢查清單

新增 background worker 時，可以依序檢查：

worker 責任是否明確：消費什麼，產生什麼，交給誰
是否有 Run(ctx) 作為生命週期入口
單次工作是否拆成 SyncOnce 或 handleUpdate
worker 是否尊重 ctx.Done()
ticker 是否 defer Stop()
channel buffer 是否有明確 backpressure 策略
queue full 是否回錯或記錄，而不是靜默丟棄
worker 是否呼叫 usecase/processor，而不是直接改 repository
測試是否避免真實長時間 sleep

設計檢查

檢查一：goroutine 要有停止條件

長時間 goroutine 需要 context、channel close 或其他退出條件。缺少停止條件時，服務運行越久，越容易累積難以診斷的資源問題。

檢查二：worker 透過 processor 或 usecase 修改狀態

worker 透過 processor 或 usecase 修改狀態，可以讓背景流程和即時流程共用同一套規則。worker 直接改 repository 時，狀態規則容易分散。

檢查三：queue full 要有明確策略

資料可以丟時，應明確記錄 log 或 metric；資料需要保留時，應 blocking 或回錯。queue full 策略明確，後續追蹤才有依據。

檢查四：測試隔離真實時間

測試優先測 SyncOnce，再用已取消 context 測 Run 的退出行為。真實 ticker 等待數秒會讓測試慢且不穩。

本章不處理

本章先處理單一背景工作如何啟動、停止與回報；cron、queue、retry 與 outbox，會在下列章節再往外延伸：

和 Go 教材的關係

這一章承接的是 goroutine 生命週期與 event processing；如果你要先回看語言教材，可以讀：

7.4 狀態管理的安全邊界

Wed, 22 Apr 2026 00:00:00 +0000

狀態管理重構的核心目標是集中寫入、保護 map、回傳複製資料，並避免讓 handler、背景工作或即時連線直接操作內部狀態。本章用一般 repository 範例說明如何建立安全邊界。

本章目標

學完本章後，你將能夠：

辨識共享狀態外洩的程式碼壞味道
用 repository 或 state owner 集中寫入
用 sync.RWMutex 保護 map、slice 與狀態不變式
用 copy boundary 防止呼叫端修改內部資料
用行為測試與 go test -race 驗證並發狀態

【觀察】共享狀態外洩會讓規則分散

共享狀態外洩的核心問題是多個元件可以繞過同一套規則直接修改資料。當 handler、worker、WebSocket client manager 都能改同一個 map，狀態不一致與 data race 會變得很難追蹤。

重構前常見寫法：

 1type Server struct {
 2    jobs map[string]JobProjection
 3}
 4
 5func (s *Server) handleJobStarted(w http.ResponseWriter, r *http.Request) {
 6    id := r.URL.Query().Get("id")
 7    s.jobs[id] = JobProjection{
 8        ID:        id,
 9        Status:    JobStatusRunning,
10        UpdatedAt: time.Now(),
11    }
12    w.WriteHeader(http.StatusAccepted)
13}
14
15func (s *Server) handleJobList(w http.ResponseWriter, r *http.Request) {
16    _ = json.NewEncoder(w).Encode(s.jobs)
17}

這段程式有三個問題：handler 直接改 map，map 沒有 lock，查詢直接輸出內部資料。只要另一個 goroutine 同時讀寫 jobs，就可能產生 data race。

【判讀】state owner 是唯一寫入入口

state owner 的核心責任是擁有資料與狀態轉移規則。它可以叫 repository、store、manager；名稱不是重點，重點是所有寫入都經過同一組方法。

 1type JobRepository struct {
 2    mu   sync.RWMutex
 3    jobs map[string]JobProjection
 4}
 5
 6func NewJobRepository() *JobRepository {
 7    return &JobRepository{
 8        jobs: make(map[string]JobProjection),
 9    }
10}

handler 不再直接改 map，而是呼叫 repository 方法：

 1func (r *JobRepository) MarkRunning(id string, now time.Time) error {
 2    if strings.TrimSpace(id) == "" {
 3        return fmt.Errorf("job id is required")
 4    }
 5
 6    r.mu.Lock()
 7    defer r.mu.Unlock()
 8
 9    job := r.jobs[id]
10    job.ID = id
11    job.Status = JobStatusRunning
12    job.UpdatedAt = now
13    r.jobs[id] = job
14    return nil
15}

這個方法把「running 狀態怎麼寫入」集中起來。未來如果 running 只能從 pending 轉移，規則也加在這裡。

【策略】鎖保護的是不變式

lock 的核心責任是保護完整狀態不變式，不只是保護某一行 map assignment。若一次狀態轉移要同時更新 current、history、updated time，就要在同一把鎖內完成。

1type JobRecord struct {
2    Current JobProjection
3    History []JobProjection
4}
5
6type JobRepository struct {
7    mu      sync.RWMutex
8    records map[string]JobRecord
9}

寫入時同時更新 summary 與 history：

 1func (r *JobRepository) Apply(event JobEvent) error {
 2    r.mu.Lock()
 3    defer r.mu.Unlock()
 4
 5    record := r.records[event.JobID]
 6    next := record.Current
 7    next.ID = event.JobID
 8    next.UpdatedAt = event.OccurredAt
 9
10    switch event.Type {
11    case "job.started":
12        next.Status = JobStatusRunning
13    case "job.succeeded":
14        next.Status = JobStatusSucceeded
15        next.Progress = 100
16    case "job.failed":
17        next.Status = JobStatusFailed
18    default:
19        return fmt.Errorf("unsupported job event type %q", event.Type)
20    }
21
22    record.Current = next
23    record.History = append(record.History, next)
24    r.records[event.JobID] = record
25    return nil
26}

這段程式讓 current 與 history 保持一致。若分散在不同 handler 或不同鎖裡，就可能留下「current 已更新但 history 沒有記錄」的中間狀態。

【執行】讀取要回傳 copy

copy boundary 的核心目標是避免呼叫端拿到內部可變資料。鎖只保護鎖內操作；一旦把內部 slice 或 pointer 回傳出去，呼叫端就可以在鎖外修改資料。

單筆查詢：

 1func (r *JobRepository) Get(id string) (JobProjection, bool) {
 2    r.mu.RLock()
 3    defer r.mu.RUnlock()
 4
 5    record, ok := r.records[id]
 6    if !ok {
 7        return JobProjection{}, false
 8    }
 9    return cloneJobProjection(record.Current), true
10}

history 查詢：

 1func (r *JobRepository) History(id string) []JobProjection {
 2    r.mu.RLock()
 3    defer r.mu.RUnlock()
 4
 5    history := r.records[id].History
 6    result := make([]JobProjection, len(history))
 7    for i, item := range history {
 8        result[i] = cloneJobProjection(item)
 9    }
10    return result
11}

clone 函式處理 pointer 欄位：

1func cloneJobProjection(job JobProjection) JobProjection {
2    cloned := job
3    if job.FinishedAt != nil {
4        finishedAt := *job.FinishedAt
5        cloned.FinishedAt = &finishedAt
6    }
7    return cloned
8}

如果 struct 未來新增 slice、map 或 pointer 欄位，clone 函式也要跟著更新。這是資料擁有權邊界的一部分。

【判讀】state 和 projection 要分清楚

state/projection 分離的核心原因是寫入規則與讀取需求不同。domain state 保存規則，projection 服務查詢與顯示。

 1type JobState struct {
 2    ID        string
 3    Status    JobStatus
 4    UpdatedAt time.Time
 5}
 6
 7type JobProjection struct {
 8    ID          string
 9    Status      JobStatus
10    Progress    int
11    UpdatedAt   time.Time
12    DisplayText string
13}

DisplayText 不應參與狀態轉移，它是 response 或 read model 的資料。若把顯示文字混進核心 state，前端文案改動就會牽動業務規則測試。

重構時不一定要一次拆出兩個 struct。可以先在程式碼中標記哪些欄位是 state，哪些欄位是 projection；等壓力變大，再正式拆型別。

【策略】handler 只請求狀態更新

handler 的核心責任是把 HTTP request 轉成狀態更新請求，而不是自己修改狀態。

重構後：

 1type JobStarter interface {
 2    MarkRunning(id string, now time.Time) error
 3}
 4
 5type JobHandler struct {
 6    jobs JobStarter
 7    now  func() time.Time
 8}
 9
10func (h JobHandler) Start(w http.ResponseWriter, r *http.Request) {
11    id := r.URL.Query().Get("id")
12    if err := h.jobs.MarkRunning(id, h.now()); err != nil {
13        http.Error(w, "start job", http.StatusBadRequest)
14        return
15    }
16    w.WriteHeader(http.StatusAccepted)
17}

handler 不知道 repository 內部用 map、slice、mutex 還是資料庫。它只知道「可以把 job 標記為 running」。

【策略】為未來資料庫保留邊界，但不提前綁死

database-ready 邊界的核心是 context、error 與一致性語意，不是提早引入 ORM。memory repository 可以先存在，但方法簽名可以保留未來 I/O 的可能。

1type JobRepositoryPort interface {
2    Apply(ctx context.Context, event JobEvent) error
3    Get(ctx context.Context, id string) (JobProjection, bool, error)
4}

memory implementation 可以忽略 context：

 1func (r *JobRepository) Get(ctx context.Context, id string) (JobProjection, bool, error) {
 2    r.mu.RLock()
 3    defer r.mu.RUnlock()
 4
 5    record, ok := r.records[id]
 6    if !ok {
 7        return JobProjection{}, false, nil
 8    }
 9    return cloneJobProjection(record.Current), true, nil
10}

未來換成資料庫時，context 可以傳給 query；error 可以包上資料庫錯誤。transaction 則等到一個 usecase 真的需要多筆寫入一致性時再設計。

【執行】state transition 測試鎖定規則

state transition 測試的核心目標是確認事件會產生正確狀態與 history。這類測試不需要 HTTP，也不需要 goroutine。

 1func TestJobRepositoryApplyRecordsHistory(t *testing.T) {
 2    repo := &JobRepository{records: make(map[string]JobRecord)}
 3    startedAt := time.Date(2026, 4, 22, 10, 0, 0, 0, time.UTC)
 4
 5    err := repo.Apply(JobEvent{
 6        JobID:      "job_1",
 7        Type:       "job.started",
 8        OccurredAt: startedAt,
 9    })
10    if err != nil {
11        t.Fatalf("apply event: %v", err)
12    }
13
14    job, ok := repo.Get("job_1")
15    if !ok {
16        t.Fatalf("job should exist")
17    }
18    if job.Status != JobStatusRunning {
19        t.Fatalf("status = %q, want %q", job.Status, JobStatusRunning)
20    }
21
22    history := repo.History("job_1")
23    if len(history) != 1 {
24        t.Fatalf("history length = %d, want 1", len(history))
25    }
26}

這個測試鎖定的是狀態規則，而不是鎖本身。

【執行】copy boundary 測試要嘗試破壞資料

copy boundary 測試的核心目標是證明呼叫端拿到的資料不能修改 repository 內部狀態。

 1func TestJobRepositoryHistoryReturnsCopy(t *testing.T) {
 2    repo := &JobRepository{records: make(map[string]JobRecord)}
 3    occurredAt := time.Date(2026, 4, 22, 10, 0, 0, 0, time.UTC)
 4
 5    _ = repo.Apply(JobEvent{
 6        JobID:      "job_1",
 7        Type:       "job.started",
 8        OccurredAt: occurredAt,
 9    })
10
11    history := repo.History("job_1")
12    history[0].Status = JobStatusFailed
13
14    again := repo.History("job_1")
15    if again[0].Status != JobStatusRunning {
16        t.Fatalf("repository history was modified through returned slice")
17    }
18}

這種測試比只看程式碼更可靠。它直接模擬呼叫端拿到資料後做了危險操作。

【執行】並發測試配合 race detector

並發測試的核心目標是讓 race detector 執行到共享狀態路徑。測試本身可以只檢查不 panic 或基本結果，真正的 data race 由 go test -race 回報。

 1func TestJobRepositoryConcurrentAccess(t *testing.T) {
 2    repo := &JobRepository{records: make(map[string]JobRecord)}
 3    var wg sync.WaitGroup
 4
 5    for i := 0; i < 100; i++ {
 6        wg.Add(1)
 7        go func(i int) {
 8            defer wg.Done()
 9
10            id := fmt.Sprintf("job_%d", i%10)
11            _ = repo.Apply(JobEvent{
12                JobID:      id,
13                Type:       "job.started",
14                OccurredAt: time.Date(2026, 4, 22, 10, 0, i, 0, time.UTC),
15            })
16            _, _ = repo.Get(id)
17            _ = repo.History(id)
18        }(i)
19    }
20
21    wg.Wait()
22}

執行：

1go test -race ./...

race detector 只能檢查測試實際跑到的路徑。若並發讀寫沒有被測試覆蓋，它也不會發現問題。

重構步驟

從共享狀態外洩重構到安全邊界，可以按這個順序：

找出所有直接讀寫 map、slice 或 projection 的地方。
建立 state owner 或 repository。
把最常用的寫入流程搬成方法。
在方法內加入 lock，保護完整不變式。
把讀取方法改成回傳 copy。
讓 handler、worker、publisher 改呼叫方法，不直接碰資料。
補 state transition 與 copy boundary 測試。
補並發測試並執行 go test -race ./...。

不要一開始就重寫所有狀態模型。先把寫入集中，再逐步整理 state/projection 與資料庫邊界。

設計檢查

檢查一：加鎖後仍要保護回傳資料

鎖只保護鎖內操作。回傳內部 map 或 slice 後，呼叫端可以在鎖外修改資料，狀態邊界仍然失效。

檢查二：讀取鎖只保護讀取

RLock 只適合讀取。只要會修改 map、slice、pointer 指向的值或 struct 欄位，就必須使用 Lock。

檢查三：狀態副本需要明確 owner

多份狀態副本會造成 source of truth 混亂。handler 應該請求同一個 state owner 更新或查詢。

檢查四：持久化替換跟著需求前進

狀態邊界是程式碼架構的責任；資料庫只負責持久化。把 memory repository 換成 ORM 只解決「資料存在哪裡」，沒有解決「誰有權利寫、怎麼寫才一致」。

引入資料庫後，清楚的寫入方法、交易語意、copy/DTO 邊界與測試仍要留在程式碼設計中。這些規則決定狀態如何被修改，不能交給資料庫連線本身代勞。

本章不處理

本章先處理 state owner、lock boundary 與 copy boundary；資料庫 transaction 與分散式一致性，會在下列章節再往外延伸：

和 Go 教材的關係

這一章承接的是 repository、read model 與 shared state 的邊界；如果你要先回看語言教材，可以讀：

小結

狀態管理重構的重點是建立資料擁有者。寫入集中在 repository 或 state owner，lock 保護完整不變式，讀取回傳 copy，handler 和 worker 只請求狀態更新。當狀態邊界清楚時，race detector 才有意義，未來換成資料庫也只是 adapter 變化，不會改變核心狀態規則。

模組四：並發模型

Wed, 22 Apr 2026 00:00:00 +0000

Go 的並發不是只會寫 go func()。Go 的並發模型包含工作如何啟動、資料如何傳遞、取消如何傳播、共享狀態如何保護。本模組從語言機制出發，再延伸到 worker、事件處理與網路服務情境。

章節列表

章節	主題	關鍵收穫
4.0	Go 並發模型總覽	看懂 goroutine、thread 與 runtime 的關係
4.1	goroutine：輕量並發工作	啟動並發工作並設計退出條件
4.2	channel：資料傳遞與 backpressure	用 channel 在 goroutine 之間傳遞資料
4.3	select：同時等待多種事件	實作 event loop
4.4	sync.RWMutex：保護共享狀態	安全讀寫共享資料
4.5	高併發控制與 backpressure	用 bounded concurrency 與 cancellation 控制壓力

本模組使用的範例主題

worker pool 與背景工作
producer / consumer 資料流
ticker 與取消訊號
共享狀態的讀寫鎖
非阻塞送出與 backpressure

學習時間

預計 90-120 分鐘

0.5 Go 和其他並發語言的差異

Thu, 23 Apr 2026 00:00:00 +0000

Go 在並發語言中的核心定位是「用較低語言複雜度寫出可部署、可維護的高併發服務」。現代語言大多能處理並發；Go 的特色在於 goroutine、channel、context、標準庫與單一 binary 共同形成一套服務工程模型。

語言比較的核心判斷是「哪一種並發模型會讓目前服務更容易寫清楚、部署簡單、長期維護」。Java、C#、Rust、Node.js、Python async、Erlang/Elixir 都能處理並發；這一章要比較的是它們各自把並發、生命週期與服務交付放在哪一種工程模型裡。

本章目標

學完本章後，你將能夠：

區分「能並發」和「適合某種並發服務」的差異
看懂 Go 的 goroutine 模型和 thread pool、async/await、actor model 的工程差異
判斷 Go 與 Java/C#、Rust、Node.js、Python async、Erlang/Elixir 的選型邊界
用工作負載、團隊維護成本與部署形態來比較語言
把語言比較轉回工程問題，形成可檢查的選型依據

【觀察】現代語言大多有並發能力

並發能力已經是現代後端語言的基本能力。Java 有 thread pool、virtual threads 與成熟框架；C# 有 Task 與 async/await；Rust 有 async runtime 與底層控制；Node.js 和 Python 有事件迴圈與 async 生態；Erlang/Elixir 有 actor 與 supervision tree。

因此，Go 的選型問題應該聚焦在「哪一種並發模型符合目前工作負載」。更有用的問題是：

這個服務主要是大量等待 I/O，還是大量 CPU 計算？
團隊希望用同步風格寫流程，還是接受 async callback / async function 傳播？
服務是否需要大量長生命週期工作單元？
部署是否重視單一 binary、啟動速度與少量 runtime 依賴？
團隊是否更重視語言簡單度、企業框架、底層控制或容錯模型？

這些問題會把語言比較轉成工程比較。語言本身只是工具，工作負載與團隊約束才是選型依據。

【判讀】Go 的差異是服務工程模型

Go 的並發模型把「工作單位」表達成 goroutine，把「取消與逾時」表達成 context，把「協調訊號」表達成 channel 或同步原語。這讓大量等待型工作可以長得像普通函式流程。

典型 Go 服務會長成這樣：

 1func handle(ctx context.Context, request Request) error {
 2    result, err := client.Fetch(ctx, request.ID)
 3    if err != nil {
 4        return fmt.Errorf("fetch data: %w", err)
 5    }
 6
 7    if err := repository.Save(ctx, result); err != nil {
 8        return fmt.Errorf("save result: %w", err)
 9    }
10
11    return nil
12}

這段程式沒有展示 goroutine，但它已經承接 Go 並發服務的核心語意：每個 request 有自己的 context，外部 I/O 接受取消，錯誤沿著呼叫鏈回傳。當這段流程被 HTTP handler、worker pool 或 queue consumer 呼叫時，生命週期仍然清楚。

Go 的優勢通常出現在三個地方：

面向	Go 的工程特性
並發工作單位	goroutine 成本低，適合大量等待型工作
生命週期控制	`context` 讓 timeout、cancel、request-scoped value 有共同傳遞方式
服務交付	編譯成單一 binary，container、CLI、sidecar 與小型服務部署簡單

這張表只是索引。下面幾節會把 Go 放到不同語言模型旁邊比較，重點是辨識每種模型適合的服務形狀。

【判讀】Go vs Java / C#：輕量服務模型與成熟平台模型

Java 與 C# 的核心優勢是成熟平台、企業框架、完整工具鏈與大型組織生態。當系統需要完整 ORM、生態整合、企業身份驗證、複雜業務框架、長期平台治理時，Java / C# 經常是穩定選擇。

接近真實網路服務的例子包括：

大型銀行或保險系統，需要完整交易、稽核、權限與企業整合
企業內部 ERP、CRM、供應鏈系統，需要成熟框架與長期治理
使用 Spring、ASP.NET、Entity Framework 等框架已經形成團隊標準的組織

Go 的差異在於服務模型更輕。當服務主要是 HTTP/gRPC API、background worker、gateway、WebSocket server、CLI 或基礎設施元件時，Go 可以用較少框架建立清楚邊界。程式啟動、部署、容器化和交接通常也比較直接。

判斷問題可以這樣問：這個系統的主要價值在成熟企業平台與框架整合，還是在小型服務、簡單部署、清楚並發生命週期？前者常偏向 Java/C# 生態，後者常讓 Go 更有吸引力。

【判讀】Go vs Rust：服務工程與底層控制

Rust 的核心優勢是記憶體安全、零成本抽象、所有權模型與底層控制。當系統需要精細控制記憶體、避免 GC pause、處理高效能底層元件或安全敏感邊界時，Rust 的能力很強。

接近真實網路服務與系統元件的例子包括：

高效能 proxy、資料處理引擎或邊緣運算元件
需要控制記憶體配置與延遲尖峰的低層服務
瀏覽器、資料庫、區塊鏈節點、嵌入式或安全敏感元件

Go 的差異在於它把 GC、簡單型別、顯式錯誤處理和 goroutine 組成服務工程預設值。團隊通常可以更快建立 HTTP service、worker、queue consumer 或內部平台工具。Go 會讓你接受 runtime 管理記憶體，換取較低心智負擔與較快服務交付。

判斷問題可以這樣問：主要風險是記憶體控制與極致效能，還是服務生命週期、部署、可讀性與交付速度？前者常讓 Rust 更合理，後者常讓 Go 更直接。

【判讀】Go vs Node.js / Python async：同步風格與事件迴圈模型

Node.js 與 Python async 的核心優勢是事件迴圈模型、豐富應用生態與快速產品整合。當服務以 I/O 為主，且團隊已經在 JavaScript、TypeScript 或 Python 生態中累積大量工具，async/await 可以建立高產能工作流。

接近真實網路服務的例子包括：

以 Next.js、Remix、FastAPI、Django 或 Flask 為核心的產品服務
需要快速串接 SaaS API、資料處理腳本、內容管理與前端整合的系統
團隊主要技能集中在 JavaScript/TypeScript 或 Python 的新產品

Go 的差異在於 goroutine 讓等待型流程看起來更接近普通同步程式。當一個 request 需要呼叫多個下游、寫入狀態、處理 timeout、再把錯誤回傳，Go 通常能把控制流程維持在直線式函式中。多核心 CPU 使用、長時間 worker、WebSocket 連線與 shutdown 流程也能用同一套 goroutine/context 模型處理。

判斷問題可以這樣問：主要價值在前端/資料/腳本生態和快速整合，還是在長時間服務、清楚生命週期與單一部署產物？前者常偏向 Node.js 或 Python async 生態，後者常讓 Go 更自然。

【判讀】Go vs Erlang / Elixir：通用服務與 actor 容錯模型

Erlang / Elixir 的核心優勢是 actor model、supervision tree、熱更新文化與分散式容錯思想。當系統需要大量獨立 actor、強調隔離、復原和訊息傳遞時，BEAM 生態有非常成熟的模型。

接近真實網路服務的例子包括：

即時通訊與 presence 系統
大量獨立 session、room、process 的通訊服務
需要 supervision tree 管理故障復原的長時間系統

Go 的差異在於它更像通用後端與基礎設施語言。你可以用 goroutine 和 channel 建立 actor-like 結構，但 Go 的標準模型更偏向明確組裝：handler、worker、repository、publisher、context cancellation、graceful shutdown。這讓 Go 在一般 API service、worker、CLI、gateway、sidecar、平台工具中更容易被多數後端團隊採用。

判斷問題可以這樣問：系統核心是否需要 actor supervision 與 fault-tolerant messaging 作為主要模型？如果答案是肯定的，Erlang / Elixir 值得認真評估；如果系統是一般後端服務與平台元件，Go 的採用門檻與部署模型通常更直接。

【策略】用比較軸選語言

語言比較應該回到可觀察的工程條件。下面這張表可以當成選型索引：

條件	更常見的候選方向
大量 I/O、長連線、worker、簡單部署	Go
大型企業框架、成熟平台治理、完整商業系統生態	Java / C#
記憶體控制、底層效能、安全敏感元件	Rust
前端整合、SaaS 串接、資料腳本、產品快速整合	Node.js / Python async
actor、supervision、分散式容錯模型	Erlang / Elixir

這張表的用途是建立第一輪比較方向。實際選型還要看團隊經驗、既有系統、部署平台、觀測工具、人才供給與維護週期。

若一個服務需要同時支援 HTTP API、背景 worker、Webhook callback、WebSocket 推送與簡單容器部署，Go 的整體組合很強。若一個產品主要依賴企業框架、動態產品流程、底層控制或 actor 容錯，其他語言可能更貼近主要問題。

【執行】把語言比較寫成工程判斷

好的語言比較結論應該包含工作負載、主要風險與取捨。語言名稱是結論，前面的工程條件才是判斷依據。

可以這樣寫：

1這個服務主要是 [webhook](/backend/knowledge-cards/webhook/) receiver、[queue](/backend/knowledge-cards/queue/) [consumer](/backend/knowledge-cards/consumer/) 與 [WebSocket](/backend/knowledge-cards/websocket/) 推送。
2主要風險是大量 I/O、[timeout](/backend/knowledge-cards/timeout/)、[backpressure](/go/backend/knowledge-cards/backpressure/) 與 [graceful shutdown](/backend/knowledge-cards/graceful-shutdown/)。
3Go 的 goroutine/context 模型和單一 binary 部署符合這些條件，所以 Go 是好候選。

也可以這樣寫：

1這個系統主要是企業內部資料管理、權限、報表與工作流。
2主要風險是業務規則完整性、框架生態、資料庫整合與長期平台治理。
3Java / C# 生態可能比 Go 更貼近主問題。

語言選型的核心輸出是「為什麼這個工作負載適合某個模型」。當比較句能說清楚工作負載、風險與取捨，團隊未來也能在條件改變時重新評估。

和本模組的關係

這一章承接 0.4 什麼時候選 Go。0.4 先判斷工作場景是否適合 Go；0.5 再把 Go 放到其他並發語言旁邊，理解它的工程定位。

讀完本章後，可以回到：

4.5 高併發控制與 backpressure

Thu, 23 Apr 2026 00:00:00 +0000

這一章處理的是一個比「會不會開 goroutine」更重要的問題：當系統真的進入高併發狀態時，怎麼讓工作量保持可控。Go 很容易啟動大量並發工作，但如果沒有邊界，goroutine、channel、下游連線與記憶體都會一起膨脹。

本章目標

學完本章後，你將能夠：

理解 bounded concurrency 的用途
用 semaphore 或 worker pool 限制同時工作數
看懂 backpressure 為什麼能保護下游
在併發流程中保留 cancellation 與 timeout
辨認什麼時候該拒絕新工作

【觀察】高併發需要容量邊界

goroutine 很便宜，但每個工作仍會消耗下游連線、記憶體、排隊時間與錯誤處理能力。當所有工作都直接丟進 go func()，被放大的通常是：

連線數
記憶體
排隊延遲
下游壓力
故障面積

高併發設計的第一原則是「可控」。系統需要知道同時有多少工作在跑、多少工作在排隊、滿載時如何回應。

【判讀】bounded concurrency 是基本保護

bounded concurrency 的核心規則是：同一時間只允許有限數量的工作進行。這可以用 worker pool、semaphore 或排隊系統達成。

 1sem := make(chan struct{}, 16)
 2
 3for _, job := range jobs {
 4 sem <- struct{}{}
 5
 6 go func(job Job) {
 7 defer func() { <-sem }()
 8 process(job)
 9 }(job)
10}

這段程式限制同時只有 16 個工作在執行。當工作量暴增時，新的工作會自然排隊，而不是把整台機器一次推爆。

【策略】backpressure 保護的是下游

backpressure 的核心規則是：當系統處理不過來時，不要無限累積工作。這可以表現成：

channel 滿了就阻塞
queue 有上限
goroutine pool 有上限
佇列滿時直接拒絕請求

例如 WebSocket、event consumer 或 background worker 如果沒有 backpressure ，輸入端一快，下游就會被放大成連鎖問題。

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

這種寫法的重點是明確表達滿載策略：系統在某些壓力下會拒絕新工作，因為保護整體健康比接住所有請求更重要。

【執行】cancellation 與 timeout 不能少

bounded concurrency 只控制數量，不能解決卡死工作。每個工作都應該保留取消訊號與 timeout，否則即使數量受限，資源也會被慢工作一直占著。

1ctx, cancel := context.WithTimeout(parent, 3*time.Second)
2defer cancel()
3
4if err := doWork(ctx, job); err != nil {
5 return err
6}

這樣可以讓每一筆工作都有自己的時間邊界，避免整體系統因單一慢點而拖垮。

【判讀】拒絕工作也是容量策略

拒絕新工作是保護容量邊界的一種策略。當以下條件成立時，拒絕通常比勉強接受更合理：

queue 已滿
下游連線池耗盡
timeout 已明顯增加
系統已進入明顯積壓

這時候回傳 429、503 或 domain-level rejection，往往比讓請求默默堆積更健康。

8.5 Twitch：直播與聊天室系統

Thu, 23 Apr 2026 00:00:00 +0000

Twitch 的案例幾乎就是 Go 教材裡高併發與即時系統的縮影。官方說法很直接：Go 被用在很多 busiest systems，上下文是 live video 與 chat，重點是 simplicity、safety、performance 與 readability。

你應該看什麼

Twitch - Go’s march to low latency GC

這個案例告訴我們什麼

Go 很適合低延遲、高事件量的即時系統。
直播與聊天室會大量依賴長連線與狀態協調。
可讀性在高壓力服務中仍然重要，因為維護者需要快速定位問題。

可對照的公開原始碼

Go case studies page

Twitch 的核心系統原始碼不是公開教學重點，所以這一章更適合把官方案例本身當成第一手材料，再回到你的 WebSocket、channel 與 backpressure 章節對照。

1.5 bounded worker pool

Wed, 22 Apr 2026 00:00:00 +0000

bounded worker pool 的核心責任是限制同時執行的工作量。goroutine 很便宜，但工作本身可能佔用 CPU、memory、file descriptor、外部 API quota 或資料庫連線；worker pool 讓容量限制成為程式設計的一部分。

預計補充內容

這些工作量邊界會在下列章節展開：

Go 入門：goroutine：背景工作與服務生命週期：先理解 goroutine 的啟動和結束方式，才知道 worker pool 為什麼要限制並發數。
Go 入門：channel：事件流與 backpressure ：job channel 的容量和阻塞行為，會直接影響 pool 的整體策略。
Go 進階：select loop 的生命週期設計：worker 的停止、排空與關閉，通常都要回到 select loop 來說明。
Backend：訊息佇列與事件傳遞：真正跨 process 的 consumer、retry 與 dead-letter 行為屬於這裡。

本章不處理

本章先把單一 process 內的工作量上限、停止與排空講清楚；跨 process 的 consumer 與 retry 機制，會放在 Backend：訊息佇列與事件傳遞。

與 Backend 教材的分工

本章只處理單一 Go process 內的工作量限制。跨 process 的 consumer group、broker partition、[dead-letter queue](/go-advanced/backend/knowledge-cards/dead-letter-queue) 與重試政策會放在 Backend：訊息佇列與事件傳遞。

和 Go 教材的關係

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

1.6 rate limiting 與 backpressure

Wed, 22 Apr 2026 00:00:00 +0000

rate limiting 的核心責任是把過量輸入轉成可預期的服務行為。服務可以等待、排隊、拒絕、降級或取樣，但這些策略應由程式明確決定，而不是讓 goroutine、channel 或 memory 自行失控。

預計補充內容

這些 backpressure 邊界會在下列章節展開：

Go 入門：channel：事件流與 backpressure ：先理解 channel buffer 和等待機制，才知道限流不是只有一種做法。
Go 進階：非阻塞送出與事件丟棄策略：當系統必須在滿載時做出明確選擇，這裡會處理 drop、覆蓋與回錯的語意。
Backend：部署平台與網路入口：跨節點流量治理、gateway 與 quota，屬於平台層責任。

本章不處理

本章先處理單一 process 內的輸入控制與 backpressure ；跨節點流量治理、gateway 與 quota 的平台責任，會放在 Backend：部署平台與網路入口。

與 Backend 教材的分工

本章只處理 Go process 內的速率控制。API gateway、load balancer、service mesh、broker quota 與跨節點流量治理會放在 Backend：部署平台與網路入口。

和 Go 教材的關係

這一章承接的是 channel backpressure 、non-blocking send 與 worker capacity；如果你要先回看語言教材，可以讀：

5.6 並發行為測試

Wed, 22 Apr 2026 00:00:00 +0000

並發測試的核心目標是驗證可觀察的同步行為，而不是猜測 goroutine 的執行順序。Go 的 goroutine 由 scheduler 安排，測試應該用 channel、context、WaitGroup 與 timeout 表達「什麼結果必須發生」。

並發測試應等待明確訊號

並發程式的核心限制是執行順序不穩定。測試如果假設某個 goroutine 一定先跑，通常會變成偶發失敗。

1func sendAsync(ch chan<- string) {
2    go func() {
3        ch <- "ready"
4    }()
5}

測試不應該在呼叫後立刻假設資料已經送出，而應該等待明確訊號。

 1func TestSendAsync(t *testing.T) {
 2    ch := make(chan string, 1)
 3
 4    sendAsync(ch)
 5
 6    select {
 7    case got := <-ch:
 8        if got != "ready" {
 9            t.Fatalf("message = %q, want %q", got, "ready")
10        }
11    case <-time.After(time.Second):
12        t.Fatalf("timeout waiting for message")
13    }
14}

select 加 timeout 可以避免測試永久卡住。timeout 不應該用來證明程式正確，只是測試失敗時的保護機制。

channel 測試要驗證傳遞結果

channel 測試的核心問題是資料是否被送到預期位置。測試應該觀察 channel 收到的值，或觀察 channel 關閉後的狀態。

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

這個函式回傳只讀 channel，呼叫端可以 range 讀取直到 channel 關閉。

 1func TestProduce(t *testing.T) {
 2    out := Produce([]string{"a", "b"})
 3
 4    var got []string
 5    for id := range out {
 6        got = append(got, id)
 7    }
 8
 9    want := []string{"a", "b"}
10    if !reflect.DeepEqual(got, want) {
11        t.Fatalf("Produce() = %#v, want %#v", got, want)
12    }
13}

這個測試沒有使用 sleep。channel 關閉就是明確完成訊號，測試可以自然結束。

context 用來測試退出

goroutine 退出測試的核心做法是提供可取消的 context.Context，再等待函式發出完成訊號。沒有退出訊號的 goroutine 很難可靠測試。

 1func RunWorker(ctx context.Context, jobs <-chan string, done chan<- struct{}) {
 2    defer close(done)
 3
 4    for {
 5        select {
 6        case <-ctx.Done():
 7            return
 8        case <-jobs:
 9            // process job
10        }
11    }
12}

測試可以取消 context，然後確認 done 被關閉。

 1func TestRunWorkerStops(t *testing.T) {
 2    ctx, cancel := context.WithCancel(context.Background())
 3    jobs := make(chan string)
 4    done := make(chan struct{})
 5
 6    go RunWorker(ctx, jobs, done)
 7    cancel()
 8
 9    select {
10    case <-done:
11    case <-time.After(time.Second):
12        t.Fatalf("worker did not stop")
13    }
14}

done channel 是測試與 goroutine 之間的完成協定。若程式沒有這種協定，測試只能猜測 goroutine 是否已經退出。

`sync.WaitGroup` 適合等待一組工作完成

WaitGroup 的核心用途是等待已知數量的 goroutine 完成。它適合 fan-out 工作、批次處理與測試中需要等多個背景任務結束的情境。

 1func ProcessAll(items []string, process func(string)) {
 2    var wg sync.WaitGroup
 3
 4    for _, item := range items {
 5        item := item
 6        wg.Add(1)
 7        go func() {
 8            defer wg.Done()
 9            process(item)
10        }()
11    }
12
13    wg.Wait()
14}

測試可以用 mutex 保護共享 slice，並在函式回傳後檢查結果。

 1func TestProcessAll(t *testing.T) {
 2    var mu sync.Mutex
 3    var got []string
 4
 5    ProcessAll([]string{"a", "b"}, func(item string) {
 6        mu.Lock()
 7        defer mu.Unlock()
 8        got = append(got, item)
 9    })
10
11    sort.Strings(got)
12    want := []string{"a", "b"}
13    if !reflect.DeepEqual(got, want) {
14        t.Fatalf("processed = %#v, want %#v", got, want)
15    }
16}

因為 goroutine 執行順序不固定，測試先排序再比較。這表示測試關心「所有項目都有被處理」，不關心處理順序。

race detector 檢查共享狀態

共享狀態測試的核心風險是 data race。Go 提供 race detector，可以在測試時檢查多個 goroutine 是否未同步讀寫同一份資料。

1go test -race ./...

-race 會讓測試變慢，但能抓出許多一般斷言看不見的並發錯誤。只要程式有 goroutine 與共享資料，定期跑 race test 就很有價值。

race detector 不是邏輯正確性的完整證明。它能檢查資料競爭，但不能保證事件順序、buffer 策略或 timeout 行為都符合需求；這些仍然要靠明確測試案例。

3.7 context：取消、逾時與生命週期

Wed, 22 Apr 2026 00:00:00 +0000

context.Context 是 Go 用來傳遞取消訊號、逾時與 request-scoped 資訊的標準機制。它的核心用途是讓一串呼叫知道「這件工作是否應該停止」。

本章目標

學完本章後，你將能夠：

理解 context 的取消語義
使用 context.WithCancel
使用 context.WithTimeout
在 goroutine 和函式呼叫鏈中傳遞 context
避免把 context 當成一般資料容器

【觀察】context 表示工作生命週期

context 的核心規則是：被取消的 context 代表這件工作不應繼續進行。長時間工作應定期檢查 ctx.Done()：

 1func Run(ctx context.Context) error {
 2 for {
 3 select {
 4 case <-ctx.Done():
 5 return ctx.Err()
 6 default:
 7 doOneStep()
 8 }
 9 }
10}

ctx.Done() 是一個 channel。當 context 被取消或逾時，這個 channel 會被關閉。

【判讀】取消是由上層傳給下層

context 的方向規則是：上層建立 context，下層接收 context；下層不應保存 context，也不應自行決定整個系統的生命週期。

1func main() {
2 ctx, cancel := context.WithCancel(context.Background())
3 defer cancel()
4
5 go worker(ctx)
6
7 waitForSignal()
8 cancel()
9}

context.Background() 是根 context。context.WithCancel 回傳子 context 和 cancel 函式。當 cancel() 被呼叫，所有使用該 context 的下層工作都會收到停止訊號。

【策略】逾時用 WithTimeout，主動停止用 WithCancel

context 建立方式的核心規則是：不知道何時停止但需要手動停止，用 WithCancel；有明確時間限制，用 WithTimeout。

1ctx, cancel := context.WithTimeout(context.Background(), 2*time.Second)
2defer cancel()
3
4if err := fetchData(ctx); err != nil {
5 return err
6}

下層函式應該接收 context：

 1func fetchData(ctx context.Context) error {
 2 req, err := http.NewRequestWithContext(ctx, http.MethodGet, "https://example.com", nil)
 3 if err != nil {
 4 return err
 5 }
 6
 7 resp, err := http.DefaultClient.Do(req)
 8 if err != nil {
 9 return err
10 }
11 defer resp.Body.Close()
12 return nil
13}

當 timeout 到達，HTTP request 會被取消。

【執行】讓背景 goroutine 有序退出

背景 goroutine 的核心規則是：啟動時接收 context，迴圈中用 select 同時等待工作與取消訊號。

 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 handleJob(job)
11 }
12 }
13}

這個 worker 有兩種退出路徑：

退出原因	對應 case
上層取消	`<-ctx.Done()`
job channel 關閉	`ok == false`

這比讓 goroutine 無限跑更安全，也比較容易測試。

設計檢查

把 context 存進 struct

context 的生命週期屬於單次操作，不應長期存在 struct 裡。通常把 context 作為函式第一個參數：

1func (s *Service) Do(ctx context.Context, input Input) error

忘記呼叫 cancel

WithCancel、WithTimeout、WithDeadline 回傳的 cancel 應該被呼叫，釋放相關資源：

1ctx, cancel := context.WithTimeout(parent, time.Second)
2defer cancel()

用 context 傳一般參數

context value 適合 request-scoped metadata，例如 request ID。一般業務參數應放在函式參數或 struct 裡。

8.10 Go 的高併發服務案例

Thu, 23 Apr 2026 00:00:00 +0000

高併發服務案例的核心判斷是「大量工作是否同時存在，且每個工作都需要清楚的生命週期」。Go 適合這類服務，因為 goroutine、channel、context、timeout 與標準網路庫可以共同描述工作如何開始、等待、取消與清理。

高併發型態

型態	主要壓力	相關案例
長連線與即時推送	大量 client、慢連線、斷線清理	Twitch、Stream、Cloudflare
網路代理與邊緣服務	timeout、連線管理、資源限制	Cloudflare、Kubernetes 生態工具
背景處理與 pipeline	fan-out、排隊、取消、錯誤回報	PayPal、Dropbox
分散式資料服務	複製、一致性、節點協調	Cockroach Labs

長連線與即時推送：先看 client 是否持續留在線上

長連線服務的核心訊號是「request 結束後，server 仍然需要替 client 保留狀態」。聊天室、直播狀態、feed 更新與即時通知，都需要管理 client 註冊、訂閱、心跳、send buffer 與清理流程。Go 的價值在於讓每條連線的讀取、寫入與取消責任能被拆成可讀的 goroutine 流程。

對應章節：WebSocket 服務架構、慢客戶端與 send buffer 管理。

網路代理與邊緣服務：先看邊界是否充滿 timeout

網路代理與邊緣服務的核心訊號是「大量 I/O 邊界同時存在」。每個 request 都可能等待 DNS、TLS、上游服務、client body 或 downstream response。Go 的 net/http、context 與 deadline 設計讓 timeout 和 cancellation 可以沿著 request 傳遞。

對應章節：net/http 與 handler 設計、context：取消、逾時與生命週期。

背景處理與 pipeline：先看工作是否可以從 request 中拆出

背景處理的核心訊號是「使用者請求只負責提交工作，真正處理需要在後面持續執行」。例如檔案轉換、通知寄送、資料同步、報表產生與 webhook retry。Go 的 goroutine 和 channel 可以先建立單一 process 內的 worker 模型；當工作需要跨 process 保證時，再接到 Backend 的 message queue 與 outbox 章節。

對應章節：bounded worker pool、Backend：訊息佇列與事件傳遞。

分散式資料服務：先看狀態是否跨節點協調

分散式資料服務的核心訊號是「資料狀態需要跨節點維持一致」。這類服務會同時處理網路延遲、節點失效、複製、leader election、transaction 與觀測訊號。Go 提供的是可讀的並發與錯誤處理基礎；資料庫演算法、共識協定與持久化設計則需要專門章節或外部資料補足。

對應章節：Source of Truth：狀態邊界、資料庫 transaction 與 schema migration。

案例閱讀檢查

閱讀高併發案例時，先找出三個問題：工作如何被限制數量、失敗如何回到 owner、資源如何被清理。若案例只談速度而沒有談生命週期，就很難轉成可維護的 Go 設計。

PostgreSQL MVCC + Lock Model：為什麼 PG 比 MySQL 少 deadlock、但 vacuum 是別的代價

Tue, 19 May 2026 00:00:00 +0000

本文是 PostgreSQL overview 的 implementation-layer deep article。Overview 已說明 PG 在 OLTP 譜系的定位、本文聚焦 MVCC + lock model — PG 並行控制機制跟跟 MySQL lock-based 不同。

PG MVCC：每次更新都新增 tuple、不改舊版

PG 的並行控制核心是 Multi-Version Concurrency Control — UPDATE 不修改原 row、是新增一個 tuple version、舊 version 留在 table 直到 VACUUM 清理：

1原 row:    (id=1, status='pending', xmin=100, xmax=NULL)
2                 ↓ UPDATE status='shipped'
3新 tuple:  (id=1, status='shipped', xmin=200, xmax=NULL)
4舊 tuple 標 xmax=200（不刪、給其他 transaction 看舊 version）

xmin / xmax 是 creator transaction id / destroyer transaction id。每個 SELECT 用 snapshot（含當下 active transaction list）判斷哪些 tuple 對自己可見：

自己 transaction id > tuple.xmin 且 (tuple.xmax = NULL 或自己 transaction id < tuple.xmax) → 可見
否則 → 看不到（過去 / 未來版本）

結果：

Readers 不 lock writers：SELECT 看 snapshot、不 block UPDATE
Writers 不 lock readers：UPDATE 寫新 tuple、不影響正在跑的 SELECT snapshot
Writers 只 lock 同一 row 的 writers：兩個 UPDATE 同 row 才 conflict

跟 MySQL InnoDB lock-based（Lock Contention）對比：

MySQL：SELECT FOR UPDATE 用 gap lock 防 phantom、deadlock 機率高
PG：MVCC + snapshot 自然防 phantom（read 看 snapshot）、deadlock 少

但 PG 代價是 VACUUM 治理 — dead tuple 不清理會佔 disk + 影響 query 效率。詳見 Autovacuum Tuning。

PG 4 種 lock

PG 仍有 lock、但場景跟 MySQL 不同：

1. Row-level lock — 主要由 UPDATE / DELETE / SELECT FOR UPDATE 取

1BEGIN;
2SELECT * FROM orders WHERE id = 100 FOR UPDATE;
3-- 對 id=100 row 加 ROW EXCLUSIVE lock
4-- 其他 transaction 試 UPDATE / DELETE id=100 必須等

Row-level lock 不 block reader（SELECT 看 snapshot、不檢查 lock）。

2. Table-level lock — DDL 跟少數 SELECT FOR 場景

PG 有 8 種 table lock mode、嚴重程度遞增：

Mode	行為	衝突
ACCESS SHARE	SELECT 跑	跟 ACCESS EXCLUSIVE 衝突
ROW SHARE	SELECT FOR UPDATE / FOR SHARE	跟 EXCLUSIVE 衝突
ROW EXCLUSIVE	UPDATE / DELETE / INSERT	跟 SHARE 衝突
SHARE UPDATE EXCLUSIVE	VACUUM / ANALYZE / CREATE INDEX CONCURRENTLY	跟同 mode + 高 mode 衝突
SHARE	CREATE INDEX（non-concurrent）	跟 ROW EXCLUSIVE 衝突
SHARE ROW EXCLUSIVE	CREATE TRIGGER / 某些 ALTER	跟 ROW EXCLUSIVE 衝突
EXCLUSIVE	REFRESH MATERIALIZED VIEW	跟所有 + 自身衝突
ACCESS EXCLUSIVE	DROP / ALTER TABLE / VACUUM FULL	跟所有衝突

DDL（ALTER / DROP）拿 ACCESS EXCLUSIVE、跟所有衝突。Production 跑 ALTER 必須短時間或走 Online Schema Change。

3. Advisory lock — Application 自己控

PG 提供 advisory lock 給 application 用、不關 row / table 結構：

1-- Session 1
2SELECT pg_advisory_lock(12345);
3-- 跑 critical section
4SELECT pg_advisory_unlock(12345);
5
6-- Session 2
7SELECT pg_try_advisory_lock(12345);  -- 試取、不阻塞、返回 false

用途：

Application-level 互斥（如：cron job 同時只跑一個）
跨 connection 同步（PG-managed mutex）
Distributed transaction coordinator（lightweight）

跟 row lock 不同：advisory lock 不關 row、application 自定義 lock ID 語義。

4. Predicate lock — SERIALIZABLE isolation 才用

PG SERIALIZABLE 用 Serializable Snapshot Isolation (SSI)、追蹤 predicate（query 條件）而不是 row：

1SET TRANSACTION ISOLATION LEVEL SERIALIZABLE;
2BEGIN;
3-- Predicate lock 紀錄這個 query 看了哪些 predicate
4SELECT * FROM orders WHERE status = 'pending';
5-- 其他 transaction INSERT pending order
6-- 提交時：PG 偵測 anomaly、rollback 之一
7COMMIT;

跟 MySQL gap lock 不同：

MySQL gap lock：pre-lock、防 phantom 在 query 期間
PG predicate lock：post-detect、commit 時偵測 anomaly、退回 transaction

PG SSI 對 寫入吞吐影響低（不 pre-lock）、但 transaction rollback 機率高（要 application retry）。

PG 預設 isolation：READ COMMITTED

PG 預設 READ COMMITTED、跟 MySQL InnoDB 預設 REPEATABLE READ 不同：

Isolation	PG 行為	MySQL InnoDB 對應
READ UNCOMMITTED	PG 視為 READ COMMITTED（不真的支援 dirty read）	MySQL 真支援
READ COMMITTED	每 statement 看當下 committed snapshot（PG 預設）	一致
REPEATABLE READ	Transaction 內 fixed snapshot（純 MVCC）	MVCC snapshot + gap lock 防 phantom（兩者都 MVCC、差在 phantom 防護機制：PG 靠 snapshot version visibility、InnoDB 加 gap lock pre-lock 範圍）
SERIALIZABLE	SSI、commit 時偵測 anomaly	強 lock + gap

對 application code 含意：

PG REPEATABLE READ 對 寫入吞吐 影響低（不 pre-lock、只 retry）
沒 gap lock → INSERT 不被 lock-induced 阻塞
Deadlock 機率比 MySQL 低數量級

實務 PG production：用預設 READ COMMITTED 即可、SERIALIZABLE 留給 strict consistency 需求（金融 / 訂單）但接受 retry。

5 個 Production 踩雷

1. Idle transaction 卡 vacuum — Bloat 暴增

PG MVCC 仰賴 VACUUM 清理 dead tuple。VACUUM 只清理 沒 active transaction 看得到的 dead tuple。如果有 idle in transaction session 持續開著（application connection pool 連線忘關 transaction）、VACUUM 看不到 該 transaction snapshot 之後的 dead tuple、累積 bloat。

修法：

監控 pg_stat_activity 看 state = 'idle in transaction' 持續時間
設 idle_in_transaction_session_timeout = '5min' — 超時 PG 自動 kill 該 session
Application connection pool 配置 不留 transaction 開著（如：pgBouncer transaction pool 自動 commit / rollback）

2. SELECT FOR UPDATE 跨 transaction — Application retry 麻煩

跟 MySQL 不同：PG SELECT FOR UPDATE 不會 block 其他 SELECT（讀仍可繼續）、但 block 其他 UPDATE / FOR UPDATE。若 application 在 transaction 內 SELECT FOR UPDATE、其他 transaction 等。

如果 application 設計 跨 transaction 持 lock（如：取 lock + return UI + 等用戶操作 + commit）、容易撞 idle in transaction 跟其他 transaction wait。

修法：

Transaction 短：取 FOR UPDATE → 立刻處理 → commit、不跨 user interaction
跨 user interaction 用 advisory lock 或 application-level state machine、不依賴 row lock

3. Advisory lock 沒釋放 — Session 結束才自動釋放

pg_advisory_lock() 拿了、沒 pg_advisory_unlock()、lock 直到 session 結束 才自動釋放。Connection pool 重複使用同 connection、可能繼承前面留的 lock。

修法：

用 pg_advisory_lock 必 try/finally pg_advisory_unlock
或用 session-level 用 transaction-scoped：pg_advisory_xact_lock() — commit / rollback 自動釋放
監控 pg_locks 看 advisory lock count、長期累積是警訊

4. Bloat 不只是 vacuum 沒跑、是 active transaction 阻擋 vacuum

第 #1 點延伸：vacuum 已跑、但 bloat 仍持續成長、原因不是 vacuum 不夠、是 active transaction 阻擋 vacuum 看 dead tuple。

修法：

不只看 last_vacuum、看 VACUUM 跑了但沒收回多少
SELECT * FROM pg_stat_progress_vacuum 看 VACUUM 進度
SELECT * FROM pg_stat_activity WHERE backend_xmin IS NOT NULL ORDER BY backend_xmin — 看誰阻擋 vacuum
詳見 Autovacuum Tuning

5. SERIALIZABLE 下 transaction rollback — Application 必須 retry

SET TRANSACTION ISOLATION LEVEL SERIALIZABLE 後、PG SSI 偵測到 anomaly 會 rollback transaction、application 看到 serialization failure、必須 retry。

對 不知道要 retry 的 application、SERIALIZABLE 變 production bug。

修法：

Application code 加 retry middleware：catch SQLSTATE 40001 (serialization_failure) → exponential backoff retry
不必所有 transaction 走 SERIALIZABLE — 只對 strict consistency 需求 場景 set
高並發 SERIALIZABLE workload 容易 rollback storm、考慮拆 transaction 縮短時間

觀測 metric

Production 監控：

pg_stat_activity：active session / idle in transaction / wait_event
pg_locks：當前 lock 列表、用 join 看誰 block 誰
pg_stat_database.deadlocks：deadlock 計數（PG 較低、但仍要監控）
pg_stat_user_tables.n_dead_tup / n_live_tup：dead tuple 比例 — bloat 指標
pg_stat_progress_vacuum：VACUUM 進度

跟 MySQL Lock Model 對比

維度	PG MVCC	MySQL InnoDB Lock
主要機制	MVCC + snapshot	Lock-based + MVCC mixed
Readers vs Writers	不互 block	預設 RR 下 gap lock 影響
Deadlock 機率	低（無 gap lock）	中-高（gap lock 主要來源）
Phantom 防護	Snapshot 自然防 + SSI predicate lock	Gap lock 預先 lock
預設 isolation	READ COMMITTED	REPEATABLE READ
成本	Dead tuple + VACUUM 治理	Lock contention 治理
Application code	SERIALIZABLE 需 retry	寫得不錯多數時 OK

兩者解決同一問題（並行控制）、用不同策略。PG 用 空間換時間（保留多版本 tuple、讀寫不互鎖、但需 VACUUM 清理）、MySQL 用 時間換空間（lock 等待、但不必清舊版本）。

選擇判讀：

High 並發 OLTP、寫 / 讀都重：PG MVCC 通常更好（讀不 block 寫）
簡單 OLTP + 不想管 VACUUM：MySQL InnoDB 對 ops 簡單
需要 SERIALIZABLE 強一致：PG SSI 對寫吞吐影響低
已有 MySQL 生態 / 工具鏈：MySQL Lock 知識可繼續用

詳見 MySQL Lock Contention — 完整 MySQL lock 機制。

跟其他模組整合

跟 Autovacuum Tuning

MVCC 仰賴 VACUUM、autovacuum 是 PG 並行控制的 維護成本。VACUUM 跑慢 / 沒跑 → bloat → query 慢。詳見 Autovacuum Tuning。

跟 Replication Topology

hot_standby_feedback = on 讓 standby 上 long-running query 不被 vacuum 取消、但 standby 把 oldest xmin 推回 primary、primary autovacuum 變保守、增加 bloat。詳見 Replication Topology。

跟 Connection Pool

pgBouncer transaction pooling 模式下、advisory lock / SELECT FOR UPDATE 跨 transaction 行為 broken（不同 transaction 可能進不同 backend connection）。詳見 pgBouncer Config。

跟 Query Optimization

長 transaction 跑慢 query 期間、其他 transaction 看到 snapshot bloat、planner 估錯 dead tuple ratio。詳見 Query Optimization。

Go 進階指南

Wed, 22 Apr 2026 00:00:00 +0000

本系列是接在入門教學之後的延伸路線，目標是把 Go 的並發模式、WebSocket 服務架構、runtime 診斷、狀態邊界與生產環境可觀測性講到能真正用在服務上。語法細節留在入門篇；進階篇聚焦長時間服務會遇到的設計壓力。

目標讀者

已完成 Go 入門實戰指南的工程師
想深入理解 Go 並發模型與 runtime 行為的開發者
需要維護長時間運行服務的人
想把 Go 服務從「能跑」提升到「可觀測、可測、可演進」的人

學習目標

掌握 goroutine、channel、mutex 的進階使用邊界
理解 WebSocket client lifecycle、heartbeat、buffer 與慢客戶端問題
使用 pprof、runtime 記憶體限制與結構化日誌診斷服務
設計 event-driven service 的資料邊界與去重策略
建立並發測試、整合測試與可重現的時間控制
能評估 Go 服務在生產環境的風險與操作策略
知道單一 Go 服務延伸到跨節點與平台整合時，哪些責任會轉移到資料庫、queue、broker、observability pipeline 與部署平台

共用術語

進階篇延續入門篇的 action、command、domain event、repository、port、adapter、projection 等詞彙。若你需要確認這些詞在這套教材中的責任邊界，可以先回到 Go 教材核心術語。

與 Backend 教材的分工

Go 進階篇處理單一 Go 服務內部的高階能力：goroutine lifecycle、WebSocket pump、runtime 診斷、event boundary、race test、graceful shutdown 與 diagnostics endpoint。當內容開始碰到資料庫、Redis、RabbitMQ、Kafka、OpenTelemetry、Kubernetes 或 CI 平台操作時，就應該轉到跨語言的 Backend 服務實務指南。

模組七保留在進階篇裡，因為它要回答「Go 服務在跨出去以前，還需要先把哪些 port、訊號與測試合約準備好」。外部系統本身的選型與部署細節，則放在 Backend，讓不同語言都能共用同一套實作知識。

教學模組

模組一：進階並發模式

從服務實例理解 fan-in、fan-out、取消傳播與 backpressure ，先把並發語意說清楚。

模組二：WebSocket 服務架構

把 WebSocket server 的連線、訂閱、推送與錯誤處理拆成可維護的邊界。

模組三：Runtime 與效能診斷

理解 Go runtime 如何在長時間運行服務中影響記憶體與排程行為。

模組四：架構邊界與事件系統

用事件驅動架構拆解服務責任，讓來源、處理與狀態不再混在一起。

模組五：測試與可靠性

針對並發服務建立能真正揭露風險的測試，而不是只追求覆蓋率。

模組六：生產操作

把本地服務推向可維護、可診斷、可部署的操作狀態。

模組七：跨節點與平台整合

承接各章「本章不處理」的延伸邊界，把單一服務往外擴張時必須補上的責任整理成一條清楚路線。

學習路徑

路徑 A：並發服務維護者

1模組一 → 模組四 → 模組五

重點：事件流、共享狀態、並發測試。

路徑 B：WebSocket/API 開發者

1模組二 → 模組六 → 模組五

重點：連線生命週期、訊息路由、操作診斷。

路徑 C：效能與可靠性工程師

1模組三 → 模組五 → 模組六

重點：pprof、goroutine leak、race check、服務操作。

路徑 D：完整學習

1模組一 → 模組二 → 模組三 → 模組四 → 模組五 → 模組六 → 模組七

按順序學習，建立完整的 Go 長時間運行服務模型。

主題延伸地圖

進階篇的章節會反覆碰到 log、time、state、event、WebSocket 與 testing。這些主題會在不同服務壓力下承擔不同責任；主題延伸地圖用來幫讀者辨識每一層的分工。

主題	單一 process 內的設計	生產操作	跨節點邊界	Backend 實作
並發與容量	channel ownership、select loop、非阻塞送出	race condition 檢查、graceful shutdown	可靠性驗證流程	Backend：可靠性驗證
WebSocket	read/write pump、heartbeat、慢客戶端	WebSocket integration test、health diagnostics	跨節點 WebSocket	Backend：快取與 Redis、訊息佇列
Runtime 診斷	GC 與 memory limit、pprof、goroutine leak	diagnostics endpoint	Observability pipeline、部署平台合約	Backend：可觀測性平台、部署平台
事件與狀態	component boundaries、source of truth、event fusion	結構化日誌欄位	outbox 與 idempotency、資料庫 transaction	Backend：資料庫、訊息佇列
測試分層	時間控制、table-driven test	race check、integration test	可靠性驗證流程	Backend：可靠性驗證

先備知識

本系列假設你已經完成 Go 入門實戰指南的基礎部分，因為下面這些章節會直接沿用那些概念：

每章結構

每章都採用「由淺到深」的結構，先說明問題，再切到設計與實作：

原理層：這個機制解決什麼問題
設計層：在服務架構中如何切責任
實作層：用簡化範例程式碼看具體做法
實戰檢查：維護時要確認哪些風險

文件版本：v0.1.0 最後更新：2026-04-22 系列狀態：核心初稿完成，延伸模組規劃中

4.0 Go 並發模型總覽

Wed, 22 Apr 2026 00:00:00 +0000

Go 的並發優勢在於 runtime 讓大量 goroutine 的生命週期、排程與阻塞管理更容易使用。處理高併發時，核心判斷是哪些工作可以並發、哪些資源需要限制，以及 runtime 如何把很多 goroutine 放到有限的 OS thread 上執行。

本章目標

學完本章後，你將能夠：

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

【觀察】goroutine 由 Go runtime 管理

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

這表示兩件事：

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

名稱	責任
process	程式執行的整體容器
OS thread	作業系統真正排程的執行單位
goroutine	Go runtime 管理的並發工作單位
runtime	負責排程、記憶體管理、阻塞處理與 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：把並發數收斂成可控容量。