概念位置

Context packing 位在 top-k retrieval 結果與 LLM prompt 之間。它跟 retrieval source 相鄰，因為來源 metadata 會影響引用；也跟 lost-in-the-middle 相鄰，因為 chunk 順序會影響模型注意力。

可觀察訊號與例子

常見 packing 決策包含 dedup 重複 chunk、把最相關內容放前後、按 document order 保留段落流、摘要或壓縮過長 chunks、在每段前加 source path 與 score。這些決策會改變答案品質、token cost 與可追溯性。

設計責任

設計 context packing 時要回答：哪些 chunk 真的要進 prompt、順序如何安排、是否保留來源、是否需要 summarization / compression。高追溯場景優先保留 source metadata；長 context 場景要避免把重要 chunk 放在中間；latency 敏感場景要限制 top-k 與 compression call。

本章目標

學完本章後，你將能夠：

1. 把 OS signal 轉成 root context 取消
2. 用 http.Server.Shutdown 停止接受新 request
3. 讓 worker、hub、WebSocket pump 觀察同一個停止訊號
4. 設計 shutdown timeout 與強制退出邊界
5. 測試 server 與 worker 的停止流程

【觀察】直接結束 process 會留下不確定狀態

Shutdown 的核心風險是停止流程不明確。服務可能正在處理 request、WebSocket client 仍在線、worker 正在寫資料、queue message 尚未 ack、diagnostics 還以為服務可接流量。

不完整停止常見後果：

• 新 request 在服務即將關閉時仍被接受。
• WebSocket client 沒收到 close，server 端 goroutine 殘留。
• 背景 worker 寫到一半被中斷。
• readiness 還是 200，負載平衡器繼續送流量。
• 測試結束後留下 goroutine 或開放 port。

Graceful shutdown 是讓停止策略可預期。

【判讀】shutdown 是多階段流程

Graceful shutdown 的核心流程是先停止接新工作，再讓既有工作收尾，最後釋放資源。

建議順序：

 1receive SIGINT/SIGTERM
 2        │
 3        ▼
 4cancel root context
 5        │
 6        ├── readiness becomes false
 7        ├── HTTP server stops accepting new requests
 8        ├── workers stop consuming new jobs
 9        ├── WebSocket hub unregisters clients
10        └── diagnostics/log records shutdown reason
11        │
12        ▼
13wait within timeout
14        │
15        ▼
16process exits

不同服務會有不同細節，但核心不變：停止訊號要集中，元件各自完成自己的 cleanup，整體流程要有 timeout。

【執行】signal 轉成 root context

Signal handling 的核心責任是把作業系統訊號轉成應用程式可理解的取消訊號。Go 1.16 之後可以使用 signal.NotifyContext。

1func main() {
2    ctx, stop := signal.NotifyContext(context.Background(), os.Interrupt, syscall.SIGTERM)
3    defer stop()
4
5    if err := run(ctx); err != nil {
6        log.Fatal(err)
7    }
8}

ctx 是 root context。HTTP server、worker、hub、diagnostics 都應從它派生出自己的 lifecycle，而不是每個元件各自監聽 signal。

Signal handler 不應放大量清理邏輯。它只負責發出停止意圖；實際清理由各元件在自己的 ownership 邊界內完成。

【執行】HTTP server 用 Shutdown 停止接新 request

http.Server.Shutdown 的核心行為是停止接受新連線，並等待既有 request 在 timeout 內完成。它比直接 Close 更適合 graceful shutdown。

 1func RunHTTPServer(ctx context.Context, handler http.Handler) error {
 2    server := &http.Server{
 3        Addr:    ":8080",
 4        Handler: handler,
 5    }
 6
 7    errCh := make(chan error, 1)
 8    go func() {
 9        errCh <- server.ListenAndServe()
10    }()
11
12    select {
13    case <-ctx.Done():
14        shutdownCtx, cancel := context.WithTimeout(context.Background(), 10*time.Second)
15        defer cancel()
16        return server.Shutdown(shutdownCtx)
17
18    case err := <-errCh:
19        if errors.Is(err, http.ErrServerClosed) {
20            return nil
21        }
22        return err
23    }
24}

Shutdown timeout 是必要邊界。沒有 timeout 的 shutdown 可能永遠等待某個卡住 request；timeout 太短則可能讓合理 request 來不及收尾。

【策略】readiness 應先變成 false

Readiness 的核心用途是控制服務是否應接新流量。Shutdown 開始後，readiness 應先變成 false，再停止 server 或等待既有工作。

 1type Lifecycle struct {
 2    shuttingDown atomic.Bool
 3}
 4
 5func (l *Lifecycle) BeginShutdown() {
 6    l.shuttingDown.Store(true)
 7}
 8
 9func (l *Lifecycle) Ready() bool {
10    return !l.shuttingDown.Load()
11}

Signal 收到後：

1lifecycle.BeginShutdown()
2cancel()

這讓負載平衡器或監控能知道服務不應再接新流量。Process 還活著，但 readiness 已經反映操作狀態。

【執行】背景工作要觀察 context

背景 worker 的核心 shutdown 條件是每個 loop 都能觀察停止訊號。Ticker、queue consumer、WebSocket hub 都應該有退出路徑。

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

若 RunOnce 可能執行很久，也應接收 context。否則外層 loop 看到 cancel，內層 I/O 或計算仍可能卡住。

【策略】WebSocket cleanup 要回到 hub owner

WebSocket shutdown 的核心原則是讓 hub 或 connection manager 統一清理 client。不要讓 signal handler 直接遍歷各種 connection 並隨意 close。

 1func (h *Hub) Run(ctx context.Context) {
 2    for {
 3        select {
 4        case <-ctx.Done():
 5            h.closeAllClients()
 6            return
 7        case client := <-h.register:
 8            h.registerClient(client)
 9        case client := <-h.unregister:
10            h.unregisterClient(client)
11        }
12    }
13}

closeAllClients 應透過 hub 的既有 owner 邏輯關閉 send、移除訂閱、關閉 connection。這延續前面模組的 ownership 原則。

【測試】shutdown 測試要觀察明確條件

Shutdown 測試的核心是確認停止訊號能讓元件退出，而不是等待固定時間。

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

HTTP server 測試可以啟動 server 後 cancel context，確認 RunHTTPServer 回傳。測試應使用隨機 port 或 httptest.Server，避免固定 port 造成衝突。

本章不處理

本章先處理服務內部的 shutdown 順序與 cleanup owner；平台 hook、timeout 與 load balancer 合約，會在下列章節再往外延伸：

• Go 進階：Kubernetes、systemd 與 load balancer 合約

和 Go 教材的關係

這一章承接的是 goroutine lifecycle、ticker cleanup 與 platform handoff；如果你要先回看語言教材，可以讀：

• Go：goroutine：輕量並發工作
• Go：defer 與資源清理
• Go：select：同時等待多種事件
• Go：goroutine leak 偵測
• Backend：部署平台與網路入口

小結

Graceful shutdown 是多階段流程：signal 轉成 root context，readiness 先關閉，HTTP server 停止接新 request，worker 和 WebSocket hub 觀察 context 收尾，整體流程受 timeout 保護。停止訊號越集中，元件 ownership 越清楚，服務在部署、測試與本機開發時越不容易留下殘存 goroutine 或未釋放連線。

資安 mitigation 的有效性不是 mitigation 本身決定的、是 mitigation × deployment 條件決定的。 同一個 mitigation 在不同 deployment / config / scale / runtime 條件下、強度光譜從「完整擋」到「等同沒部署」都可能。寫作時忽略 deployment 變數、讀者實作時用最直覺條件詮釋、實際部署條件不對 mitigation silent 失效。

差別在於：reader 在實作 review 階段有沒有 context 變數可檢查。

情境

資安 mitigation 在文獻 / 標準 / 教學裡常被描述成「方法 → 防什麼 threat」對應、跳過 deployment 條件這個變數。讀者讀完套到自己 deployment 上、條件可能不一致。常見的 context dimension 有四類：

Context 維度 1：Config 完整性

Mitigation 通常需要多個 config 同時成立才有效、單一 config 不夠：

1HTTPS 防中間人：成立條件 = TLS + HSTS + cert pinning（針對重要 endpoint）+ CT log monitoring
2                失效條件 = 只有 TLS、沒 HSTS → 第一次連線可被 downgrade
3                          沒 cert pinning → 受信任 CA 簽出假 cert 可繞過
4JWT 驗身分：    成立條件 = 簽章驗證 + 短 TTL + rotation + 安全儲存（HttpOnly cookie 或 secure storage）
5                失效條件 = 簽章對但 TTL 太長 → token 被竊後長期可用
6                          XSS 可讀取 → 簽章保護被繞過
7                          沒 rotation → 一次外洩永久暴露

寫「使用 HTTPS」「使用 JWT」是把 mitigation 縮成單一 control name、reader 預設 default config、實際要 5-7 個 config 同時對才完整。

Context 維度 2：Scale / 多實例

某些 mitigation 在單機 OK、多實例失效：

1Rate limit： 單實例 = local counter、per-IP rate 控管準確
2            多實例 = 每實例各自 count、攻擊者打不同實例可繞過 N 倍上限
3            修法 = 用 distributed counter（Redis / 共享 store）
4Session 失效：單實例 = local session store、invalidate 即時
5            多實例 = invalidate 訊號需 broadcast、舊 token 在其他實例還可用
6            修法 = 用 stateless token + revocation list 或 共享 session store

Reader 看到「rate limit 防 brute force」、實作時若不知道 deployment scale、單實例 OK / 多實例 silent 失效。

Context 維度 3：Runtime 環境

執行環境差異改變 mitigation 適用性：

1Cookie SameSite=Strict 防 CSRF：
2  瀏覽器環境 = 有效（瀏覽器強制執行）
3  Native app webview = 部分有效（依 webview 實作）
4  Mobile in-app browser = 不一定有效（看實作）
5  Server-to-server = 不適用（無 cookie / 無 SameSite 概念）
6CSP 防 XSS：
7  Modern browser = 有效
8  舊瀏覽器（IE / 非 evergreen）= partial 或無效
9  非 browser execution（Electron / native webview）= 看 implementation

Context 維度 4：Threat actor 能力

Mitigation 的 work factor 跟 threat actor 計算能力對應：

1bcrypt（work factor = 10）：
2  個人攻擊者 = 強保護
3  Nation-state（GPU farm / FPGA）= 弱保護、需提高 work factor 或換 argon2
4PBKDF2（100k iterations）：
5  2010 年 = 強
6  2026 年 = 弱（建議升級到 600k+ 或 argon2）

Threat actor 能力是 deployment 隨時間變化的變數、寫作時固定描述很快過時。

理想做法

每個 mitigation 段落明示三類條件：

三類條件模板

1[Mitigation X]
2- 成立條件：[X 發揮設計強度需要的 config / scale / runtime / 其他 control 配套]
3- 失效條件：[條件不對時 X 變成 etc 等同沒部署的具體情境]
4- Deployment 變數：[實作時要檢查的 dimension list]

例（rate limit 防 brute force）：

1per-IP rate limit
2- 成立條件：單實例部署 OR 多實例 + distributed counter（Redis / 共享 store）
3- 失效條件：多實例 + local counter、攻擊者輪流打不同實例繞過上限
4- Deployment 變數：實例數量、counter 部署位置（local / shared）、IP 來源真實性（NAT / proxy 後是否還能 distinguish）

例（HTTPS 防中間人）：

1HTTPS
2- 成立條件：TLS + HSTS（避免首連線 downgrade）+ 受信 CA chain + 在重要 endpoint 配 cert pinning
3- 失效條件：沒 HSTS → 首次連線 downgrade；CA 被攻陷 → 假 cert 可繞；no cert pinning + state-level CA 攻陷 → silent MITM
4- Deployment 變數：HSTS preload / max-age 設定、cert pinning 範圍（哪些 endpoint）、CA list 是否最小化、CT log monitoring 是否到位

Context 描述的層次規則

每個 mitigation 描述至少要有 deployment baseline 跟 stretch case：

baseline 給 reader 入門條件、stretch 給 reader 升級判準、trigger 讓升級成 actionable signal。

跟「規模改變可行性」的同骨

跟 #89 Dataset 規模改變什麼可行 同骨——#89 在 dataset / index / cache 維度、本卡在 mitigation / config / scale 維度：

1#89:    < 1MB 無腦處理 → 1-10MB O(N) 可行 → > 100MB 強制 index
2本卡：   單實例 local rate limit OK → 多實例需 distributed counter → 高 scale 需 token bucket + adaptive

「在 X 規模 / 條件下 Y 方法 OK」這個結構在資料處理跟資安都成立、是 deployment 變數驅動的工程光譜。

沒這樣做的麻煩

「正常條件下有效」silent 變成生產破口

讀者讀「使用 X 防 Y」、用自己 deployment 的 default config 實作、跑開發測試 OK、ship 進生產。生產可能是多實例 / 高 scale / 異常 runtime、X 在那條件下不成立、threat 進入。Mitigation 在開發環境 silent 失效、生產環境 silent 失效——兩階段都沒訊號、直到事件。

跟 #100 false sense of security 同病：context 沒寫、reader 用最直覺條件詮釋、condition mismatch 不會被 catch。

Mitigation 升級的時機不可 trace

威脅環境變化（actor 計算能力 / 攻擊變體 / scale 增長）需要 mitigation 跟著升級。Context 寫清楚的 mitigation 可 trace（bcrypt work factor 跟 actor 能力對應、定期 review）；context 含糊的 mitigation 不可 trace（「使用 bcrypt」變成 frozen「最佳實踐」、實際強度跟著時間 decay）。

跨環境 deployment 的 mitigation 假設衝突

同一份教學 / spec 套到不同 deployment（dev / staging / prod / 多區域 / 不同租戶）、若 context 沒寫、各 deployment 的 mitigation 強度差異被 silent。Audit 跨 deployment 時無法判定哪個強度最弱、整個系統的 baseline 取決於最弱 deployment、但沒人知道哪個是最弱。

跟其他抽象層原則的關係

判讀徵兆

適用範圍與邊界

• 適用：資安 mitigation 的所有論述（auth / crypto / 傳輸 / 防護 / scale-sensitive control）；任何「方法有效性受部署條件影響」的領域（concurrency primitive 在不同 memory model / DB transaction 在不同 isolation level / consensus 演算法在不同 network partition 假設）
• 不適用：純歷史 / 概念介紹（不教 mitigation deployment）、研究探討（讀者預期自行 explore condition）
• 邊界：「Context-dependence 顯式」≠「窮舉所有 deployment 排列組合」——只列 reader 直覺會誤判的 dimension（最常見 deployment 跟最常見變體）、不必涵蓋整個 deployment space；判別準則：「reader 用 default 條件詮釋會不會 silent 失效」——會 → 補 context、不會 → 不必補
• 過度條件化反例：每個 mitigation 列 deployment matrix（10 個 dimension × 5 個值 = 50 個 case）、文章變 deployment guide、不是教學；條件描述的投資量級對應 mitigation 在系統的責任比重——核心 control（auth / crypto）值得三類條件完整、輔助 control 只列 baseline + 一個 stretch case 即可

本卡是資安 audit 第三個維度（context-dependence）、配 #101 threat model + #102 對位、後續 #104 citation 形成完整 audit dimension 集合。