Golang 教學：通道的進階用法 ── 單向通道 (Unidirectional Channels)

---

簡介

在 Go 語言中，通道（channel） 是實作 goroutine 之間安全通信的核心機制。大多數入門教材只會示範「雙向通道」的基本使用方式，然而在實務開發裡，我們常常需要 限制資料流向，以避免不小心把寫入或讀取的權限交給錯誤的程式碼區塊。這時候 單向通道（unidirectional channel）就派上用場。

單向通道不僅能提升程式的可讀性與安全性，還能在大型專案中減少競爭條件（race condition）的發生機率。本文將從概念說明、實作範例、常見陷阱與最佳實踐，逐步帶你掌握單向通道的使用技巧，讓你在 Go 的併發程式設計上更上一層樓。

---

核心概念

1. 什麼是單向通道？

在 Go 中，通道的類型可以寫成 chan T（雙向）、<-chan T（只能接收）或 chan<- T（只能傳送）。

• chan<- T → 只能寫入，不能從中讀取。
• <-chan T → 只能讀取，不能向裡面寫入。

這樣的限制是 編譯期（compile‑time） 強制的，若程式嘗試違反方向，編譯器會直接報錯，從根本上避免了許多邏輯錯誤。

var (
    // 雙向通道
    bidir  chan int = make(chan int)

    // 單向寫入通道
    sendOnly chan<- int = bidir

    // 單向接收通道
    recvOnly <-chan int = bidir
)

重點：單向通道本身仍然是底層的雙向通道，只是對外「包裝」了一層方向限制。

---

2. 為什麼要使用單向通道？

需求	使用雙向通道的風險	單向通道的好處
API 設計：只想讓呼叫者寫資料，不能讀回	呼叫者可能誤用 <- ch 讀取，導致 deadlock	編譯期保證只能 ch <- value
工作者池（worker pool）：主程式只發送任務，工作者只接收	若工作者意外寫回，會破壞通道的語意	方向限制讓程式碼意圖更明確
資料流管線：多段處理流程，每段只負責「接收 → 處理 → 發送」	任何段落都能隨意讀寫，容易產生循環依賴	每段只接受前一段的輸出、只發送給下一段

---

3. 單向通道的宣告與轉型

單向通道通常在 函式參數 或 返回值 中使用，讓呼叫者只能執行允許的操作。

// 只接受寫入的函式
func produce(ch chan<- int, nums []int) {
    for _, n := range nums {
        ch <- n // 只能寫入
    }
    close(ch) // 結束訊號
}

// 只接受讀取的函式
func consume(ch <-chan int) {
    for v := range ch {
        fmt.Println("收到:", v) // 只能讀取
    }
}

如果你已經有一個雙向通道，想要傳遞給只接受寫入的函式，只需要 隱式轉型：

c := make(chan int)
go produce(c, []int{1, 2, 3})
go consume(c)

在 produce 中，參數 ch 被視為 chan<- int，編譯器會自動把 c 轉成單向寫入通道；同理 consume 只會看到 <-chan int。

---

4. 範例一：簡易的生產者 / 消費者管線

下面示範一條 單向管線，包含三個階段：產生資料 → 轉換 → 輸出。每個階段都只保有必要的方向權限。

package main

import (
    "fmt"
    "sync"
)

// 產生整數序列
func generator(out chan<- int) {
    for i := 1; i <= 5; i++ {
        out <- i
    }
    close(out)
}

// 把整數平方
func squarer(in <-chan int, out chan<- int) {
    for v := range in {
        out <- v * v
    }
    close(out)
}

// 印出結果
func printer(in <-chan int, wg *sync.WaitGroup) {
    defer wg.Done()
    for v := range in {
        fmt.Println("結果:", v)
    }
}

func main() {
    ch1 := make(chan int)
    ch2 := make(chan int)

    var wg sync.WaitGroup
    wg.Add(1)

    go generator(ch1)          // 只寫入 ch1
    go squarer(ch1, ch2)       // 只讀 ch1、只寫 ch2
    go printer(ch2, &wg)       // 只讀 ch2

    wg.Wait()
}

說明

• generator 只接受 chan<- int，保證不會誤讀。
• squarer 同時擁有 <-chan int（讀）與 chan<- int（寫），形成 雙向 的中介，但每個方向都是明確的。
• printer 只讀 <-chan int，不會意外寫回。

---

5. 範例二：使用 select 搭配單向通道

在多路復用（multiplex）情境下，select 常與多個通道一起使用。單向通道可以讓 select 的 case 更具語意。

func fanIn(done <-chan struct{}, chans ...<-chan int) <-chan int {
    out := make(chan int)
    var wg sync.WaitGroup
    wg.Add(len(chans))

    for _, ch := range chans {
        go func(c <-chan int) {
            defer wg.Done()
            for {
                select {
                case v, ok := <-c:
                    if !ok {
                        return
                    }
                    out <- v
                case <-done:
                    return
                }
            }
        }(ch)
    }

    go func() {
        wg.Wait()
        close(out)
    }()
    return out
}

• done 為 只讀 的取消訊號。
• chans 為 只讀 的來源通道陣列。
• out 仍是雙向通道，因為 fanIn 必須把資料寫回給呼叫端。

---

6. 範例三：限制 API 的寫入權限

假設你要提供一個「事件推播」的套件，外部只能 發送 事件，不能直接關閉通道或讀取。

// event.go
package event

type Event struct{ ID int }

// NewPublisher 建立只允許寫入的通道
func NewPublisher(buf int) chan<- Event {
    ch := make(chan Event, buf)
    // 內部啟動一個 goroutine 處理事件
    go func() {
        for e := range ch {
            // 處理或轉發事件
            fmt.Println("處理事件:", e.ID)
        }
    }()
    return ch // 只回傳 chan<- Event
}

外部程式只能呼叫 pub <- Event{ID: 42}，無法直接 close(pub) 或 <-pub，避免了資源釋放與資料競爭的問題。

---

常見陷阱與最佳實踐

陷阱	說明	解決方式
把雙向通道直接暴露	若函式返回 chan T，呼叫者可以同時讀寫，破壞封裝。	返回單向通道（chan<- T 或 <-chan T）讓權限最小化。
忘記關閉通道	只寫入端關閉，讀取端仍在等待，導致 deadlock。	在產生端完成後 close(ch)，或使用 sync.WaitGroup 追蹤生命週期。
在單向通道上使用 len、cap	這兩個內建函式只能接受雙向通道。	若真的需要，先把單向通道轉型為雙向：len(<-chan T)(ch)（不建議，除非真的必要）。
將單向通道傳給錯誤的函式	方向不匹配會編譯錯誤，若使用 interface{} 包裝會失去檢查。	盡量避免使用 interface{} 包裝通道，保持具體類型。
在 select 中混用單向與雙向通道	會造成程式可讀性下降。	在 select 前統一使用 單向，讓每個 case 的意圖清晰。

最佳實踐：

1. 最小化權限：只把需要的方向暴露給呼叫者。
2. 明確命名：使用 in、out、sendOnly、recvOnly 等名稱，讓程式碼自說自話。
3. 使用 sync.WaitGroup 或 context.Context 來協調 goroutine 終止，避免因通道未關閉而造成資源泄漏。
4. 在文件中註明通道的生命週期（誰負責關閉、誰負責讀寫），減少團隊溝通成本。

---

實際應用場景

1. 微服務間的事件流

   • 每個服務只負責 發送 事件到 Kafka，外部只能寫入 chan<- Event，避免服務意外讀取或關閉通道。

2. 資料處理管線（pipeline）

   • 多階段 ETL 流程中，每個階段只接受前一階段的輸出（<-chan T）並產生下一階段的輸入（chan<- T），確保資料只能向前流動。

3. 工作者池（worker pool）

   • 主程式把任務寫入 chan<- Task，工作者只讀 <-chan Task，不會把結果寫回同一通道，降低競爭。

4. 測試框架的 Mock

   • 測試時可以把 chan<- int 替換成一個只接受寫入的 假通道，驗證程式是否正確呼叫 Send，而不必關心接收端的實作。

---

總結

單向通道是 Go 語言中 編譯期保護 的利器，透過限制資料流向，我們可以：

• 提升程式可讀性：每個函式的參數類型直接表明它只能做什麼。
• 減少錯誤：錯誤的讀寫操作會在編譯階段被捕捉。
• 加強封裝：API 只暴露必要的權限，避免資源被濫用。

在實作上，只需要在宣告或函式簽名中使用 chan<- T 或 <-chan T，配合 close、sync.WaitGroup、context.Context 等工具，就能建立安全、可維護的併發系統。希望本篇文章能讓你在日常開發中自然地採用單向通道，寫出更乾淨、更可靠的 Go 程式碼。祝開發順利！ 🚀