Python 迭代協議與串流計算：Iterable 與 Iterator 的職責分離與權衡

如果用 Python 嘗試以串列（list）一次載入 100GB 的記錄檔（log），行程會迅速觸發記憶體不足（OOM），接著被作業系統終止。將程式碼改為以迭代器串流讀取後，記憶體用量能立刻降至常數級別。但當你試圖呼叫 len() 取得總筆數時，程式會拋出 TypeError；若對同一個串流進行第二次遍歷，後續運算又會靜默地收到空資料。

如果你剛接觸 Python，或是依照一般思路撰寫程式碼，上述問題可能會讓你感到困惑（當然，由 AI 生成的程式碼應該不會看到這類問題，但底層原理仍需要理解）。

許多工程師能熟練地撰寫 for x in data: 來遍歷序列，卻時常將「資料持有者」與「進度推進器」混為一談。這種認知上的模糊很容易在線上環境引發缺陷，例如在巢狀迴圈中互相踩踏狀態，或是誤把一次性串流當成可重複使用的集合。

掌握 Python 迭代體系的關鍵，在於理解 Iterable 與 Iterator 的職責分離。

我們將沿著一條清楚的工程認知路徑展開：

要徹底建立串流計算的心智模型，必須先回答一個基礎架構問題：為何 Python 不讓容器直接記錄自己的讀取進度？我們就從容器與游標解耦的契約切入。

如果讓串列本身記錄遍歷進度，雙層巢狀迴圈會立刻失控。當外層迴圈讀到第 2 個元素時，只要內層迴圈一啟動，就會把容器內部的游標重置或推到最尾端，導致外層迴圈的狀態被直接覆蓋。

為了解決狀態衝突，Python 在設計上將「資料持有」與「進度推進」解耦為兩組角色：可迭代物件（Iterable）與迭代器（Iterator）。

可迭代物件（Iterable）是資料的持有者，負責儲存並提供資料存取入口；迭代器（Iterator）則是單向推進的游標，僅負責維護目前的讀取偏移量。

直覺模型： 可迭代物件就像一本靜態出版的書籍，迭代器則是讀者夾在書中的書籤。多位讀者可以各自持有一枚書籤閱讀同一本書，彼此的翻頁進度互不干擾。

可迭代物件與迭代器的常見混淆： 常被誤以為能直接放進 for 迴圈的物件就是迭代器。實際上，list、tuple、dict 都只是可迭代物件（Iterable）。它們本身沒有任何游標狀態，無法記錄「目前讀到哪裡」。

這種解耦在概念上帶來了額外的狀態管理成本：每次啟動遍歷時，執行階段都需要實例化一個新的迭代器游標（在 CPython 等直譯器中會在堆積記憶體上配置新物件）。雖然在未經 JIT 或編譯最佳化的場景下會產生微小的記憶體配置成本，但它換來了多游標獨立遍歷與並行存取的安全性。

Python 的 for 迴圈本質上不是以索引遞增為基礎的計數迴圈，而是基於迭代協議驅動的語法糖。它透過明確取得游標、持續步進、捕捉終止訊號三個步驟完成遍歷。

以下是用底層協議等價還原 for 迴圈的邏輯：

機制與代價分析：

若要實作標準迭代協議，程式碼必須明確拆分為「資料持有者」與「獨立游標」兩個角色。

在 Python 的迭代協議中，資料持有者負責儲存資料，並在每次提出請求時提供全新的游標。游標類別則負責維持單向推進的狀態。

Python 迭代協議採用鴨子型別，因此不要求強制繼承特定類別。只要物件實作指定的魔術方法，就能符合協議契約。游標類別本身必須同時實作 __next__() 與 __iter__()。

自參照設計的因果鏈：

NumberCursor 的 __iter__ 方法會直接回傳 self，因此 NumberCursor 可同時作為 Iterator 與 Iterable 使用。

當開發者將已取得的游標物件直接傳給 for 迴圈、zip() 或 enumerate() 時，直譯器呼叫 iter(cursor)，仍能正確取得游標本身。標準函式庫模組 collections.abc.Iterator 正是從抽象基礎類別層級，預先提供會回傳 self 的 __iter__ 模板方法。

容易混淆之處與邊界代價：

一般可迭代容器常被誤以為也能在 __iter__ 中直接回傳 self。實際上，一旦容器回傳自身，就會退化為只能遍歷一次的一次性資料流，進而導致巢狀迴圈彼此干擾。

手動採用雙類別模式，可確保狀態完全解耦，但也會產生額外的工程樣板程式碼。若沒有複雜的狀態流程，手動類別會比生成器語法更加冗長。

Python 內建容器的迭代器，在底層記憶體結構與並行修改偵測機制上有本質上的差異。

為降低雜湊表結構變更帶來的風險，CPython（3.6 以上版本）會在字典結構中維護遞增的版本號 ma_version。字典每次新增或刪除鍵時，該版本號都會變更。字典迭代器（dict_keyiterator）建立時會記錄當時的版本號，並在每次執行 next() 時比對版本值。一旦發現不一致，直譯器便立即拋出 RuntimeError: dictionary changed size during iteration，採取快速失效（Fail-Fast）機制。

邊界與適用條件：

字典版本驗證僅針對會改變資料表結構的新增與刪除操作。遍歷過程中，若原地修改既有鍵所對應的 value，並不會改變 ma_version，因此屬於合法操作。

手動游標類別雖然能確保職責解耦，但每個資料流都需要維護個別類別。下一章將說明如何運用生成器簡化這個流程。

生成器物件（Generator Object）在底層完全符合迭代協議契約。它並非獨立於迭代體系之外的全新技術或概念，而是 Python 消除手寫游標樣板程式碼的高階封裝。

我在早期的開發過程中，無論是 TypeScript 還是 Python，總是把生成器誤以為是脫離迭代體系的獨立技術概念。其實在 Python 的型別系統與執行階段中，生成器本質上就是一種標準的迭代器。

定義包含 yield 的函式在被呼叫時，並不會直接執行函式主體，而是回傳一個生成器物件。

因果鏈與機制：

易混點： 常被誤以為生成器是脫離迭代體系的獨立技術概念，其實它在介面與行為上與迭代器完全同構。

包含 yield 的函式本身只是生成器物件的工廠。呼叫函式後回傳的生成器實例，才是真正的單向迭代器游標。

邊界與代價： 生成器免去了手寫游標類別的樣板程式碼。但它的內部游標偏移完全封裝在執行階段的堆疊框中。開發者無法像存取自訂類別屬性那樣（例如 cursor.index），直接讀取或重設其內部狀態。

串流計算的本質是用時間換取空間。生成器透過在執行階段掛起與恢復堆疊框，實現按需產生單一元素。

底層原理與執行機制（基於 CPython 3.8+）： 當執行流程到達 yield 陳述式時，直譯器會將生成器堆疊框標記為掛起狀態。執行階段會完整保留目前堆疊框中的區域變數表，以及最後的指令偏移量（f_lasti），接著把值回傳給呼叫方。函式此時並不會銷毀執行堆疊框。

當呼叫方下一次執行 next(gen) 時，直譯器會將執行上下文切回該生成器堆疊框。控制流程會直接從 f_lasti 記錄的下一條位元組碼指令繼續執行，直到遇到下一個 yield，或函式執行完畢並回傳。

直覺模型：

權衡與代價： 惰性求值將空間複雜度從 O(N) 降低到 O(1)，消除了處理海量資料時的記憶體不足（Out of Memory / OOM）風險。

但這種空間最佳化付出了 CPU 吞吐量的代價。生成器在每個元素產出時，都要經歷堆疊框的掛起與恢復。如果生成器管線巢狀層級過深，頻繁的堆疊框上下文切換與函式排程開銷，會導致整體 CPU 耗時明顯高於連續記憶體的一次性批次計算。

串流迭代器將記憶體複雜度壓至 O(1)，代價是放棄隨機存取、長度預知與重複遍歷的能力。這種設計在處理無限資料流時極為高效；然而在一般業務情境中，若重複消費已耗盡的迭代器，程式不會報錯，而是直接回傳空集合，極容易導致下游資料被靜默漏算。

迭代器游標在記憶體中僅保存當前推進位置，既不保留已存取的歷史紀錄，也不預讀尚未遍歷的後續元素。這種輕量化設計，直接造成序列操作能力的全面喪失。

因果鏈與代價分析：

易混淆點：itertools.tee 的記憶體陷阱：

itertools.tee 常被誤以為可以零成本地複製多條獨立的串流迭代器。

實際上，itertools.tee 會在各分支迭代器之間共享資料來源，內部以先入先出（FIFO）佇列緩衝尚未被所有分支讀取的元素。

若其中一個分支快速消耗資料，而另一個分支處理緩慢，緩衝佇列將持續堆積元素。此時空間複雜度會從 O(1) 退化至 O(N)，最終可能引發記憶體不足（OOM）。

在正式環境的程式碼中引入迭代器與生成器時，必須明確防範狀態耗盡、併發衝突與資源洩漏三類風險。

當生成器作為參數在多個業務函式之間傳遞時，若前置函式已進行完整遍歷，或呼叫了 any()、max() 等消費型內建函式，游標就會被直接耗盡。後續函式再次讀取時，會因取得空資料而產生計算偏差。

防禦模式：若確認資料規模較小且需多次使用，應在入口處明確呼叫 list(stream) 轉為靜態列表；若資料規模過大、無法全量載入記憶體，則應重構函式，改為接收「生成器工廠」（每次呼叫回傳全新的迭代串流），而非直接接收迭代器實例。

Python 迭代器的推進操作並非原子操作。在多執行緒環境下，若多個工作執行緒同時對同一個迭代器呼叫 next(iter)，內部游標狀態會發生資料競爭（Race Condition），導致部分元素被重複處理，或部分元素被直接略過。

防禦模式：禁止跨執行緒共用裸迭代器。多執行緒分派任務時，應將資料預先推入執行緒安全的 queue.Queue，或在呼叫 next() 時明確使用互斥鎖（threading.Lock）進行同步保護。

生成器常被用來封裝外部 I/O 資源（例如檔案描述元或資料庫游標）。若外部呼叫端在遍歷過程中透過 break 提前離開，生成器函式會停留在掛起狀態，其內部持有的系統資源可能無法即時釋放。

防禦模式：生成器內部申請的任何底層系統資源，必須使用 try...finally 區塊或 with 上下文管理器（context manager）加以保護。當呼叫端提前跳出迴圈時，生成器物件在被垃圾回收階段會觸發內部的 GeneratorExit 例外，finally 區塊可確保底層控制代碼（handle）被強制釋放。

Python 透過 Iterable 與 Iterator 協定分離，實現多游標遍歷與惰性流式計算，以 O(1) 記憶體換取隨機存取與可重播能力。