羅培宸的技術筆記：從面試戰場到 AI 實戰: PHP 全端工程師面試指南：深度解析與實戰經驗分享

PHP 全端工程師面試指南：深度解析與實戰經驗分享

這篇文章彙整了我在PHP全端工程師職涯中，針對常見面試問題的深度解析與實戰經驗。內容涵蓋了PHP生態、框架應用、測試、安全營運，以及系統設計與實作題，希望能為您帶來啟發。

PHP 與生態

你常用哪個 PHP 版本與理由；遇到相容性問題怎麼解決？

作為一位擁有10年以上經驗的全端工程師，我目前最常用 PHP 8.2 或 8.3 版本（截至2025年，PHP 8.3 已廣泛穩定）。選擇這些版本的原因主要基於性能、安全與生態相容性考量：

性能提升：PHP 8.x 引入了 JIT 編譯器、屬性（Attributes）、聯合類型（Union Types）和枚舉（Enums），這些功能讓程式碼更簡潔、安全且高效。相較 PHP 7.x，8.x 在基準測試中平均快 10-20%，尤其在 CPU 密集型任務如資料處理或 API 呼叫時。

安全性與維護：PHP 8.x 具有更好的類型安全（如 Constructor Property Promotion），能有效減少常見錯誤。同時，官方支援週期較長（8.3 活躍支援至 2025 年底，安全支援至 2027 年），有助於避免舊版潛在的安全漏洞。

生態相容：目前大多數流行的框架如 Laravel 11.x、Symfony 7.x 都原生支援 8.x，且 Composer 套件也多已升級，確保開發順暢。

遇到相容性問題的解決策略：

預防為主：在專案初始化時，透過 composer.json 指定最低 PHP 版本（例如："php": "^8.2"），並定期運行 composer validate 和 phpcs 檢查程式碼規範和潛在問題。

診斷工具：利用 php -l 快速檢查語法錯誤，或使用 PHPStan/Psalm 等工具進行靜態分析，提早發現不兼容的程式碼。對於舊套件可能的不兼容，需密切關注 PHP 8.x 內建的 deprecation 警告日誌。

解決方案：

逐步升級相關套件。

使用 polyfill 套件（如 symfony/polyfill-php81）來橋接舊版功能與新版 API。

若套件實在無法升級，則考慮 fork 該套件自行維護，或尋找替代方案。

在生產環境中，我習慣使用 Docker 容器化技術，以便於在不同 PHP 版本之間進行並行測試，減少風險。

實務案例：我曾將一個 PHP 7.4 的老舊專案升級到 8.2。整個過程透過 CI/CD pipeline 自動化測試相容性，有效減少了潛在的 downtime 和人工檢查成本。

Composer 套件管理策略、私有套件的發布與版本策略。

Composer 是 PHP 套件管理的核心，我的策略強調穩定性、依賴最小化和嚴格版本控制。

Composer 管理策略：

依賴最小化：只安裝專案必需的套件，並傾向於安裝穩定版本（composer require --prefer-stable）。定期運行 composer outdated 檢查可更新的套件，並使用 composer why 診斷依賴衝突。

鎖定版本：始終使用 composer.lock 檔案鎖定所有套件的精確版本，避免在不同環境或不同時間點因套件意外升級而引發問題。開發時，我會使用 SemVer 的 ^ 語義版本來允許小版本更新；但在生產環境，則傾向於使用精確版本以確保環境一致性。

環境分離：將開發和測試工具（如 PHPUnit）安裝在 require-dev 中，並在生產環境部署時使用 composer install --no-dev，剝離不必要的開發依賴，縮小部署包。

安全檢查：整合 sensiolabs/security-checker 或 roave/security-advisories 等工具到 CI/CD 流程中，自動檢查已知漏洞的套件。

私有套件的發布與版本策略：

發布方式：我會使用私有 Composer 倉庫，例如 Satis 或 Packagist 的私有版。在專案的 composer.json 中，透過 repositories 設定指向 GitLab 或 Bitbucket 上的私有 Git 倉庫。發布新版本時，我會使用 Git tag 標記版本號（如 v1.2.3），並將 tag push 到遠端倉庫。

版本策略：嚴格遵守 語義化版本（Semantic Versioning, SemVer）：

Major 版本（X.x.x）：表示有破壞性變更（breaking changes）。

Minor 版本（x.Y.x）：新增功能，但保持向下兼容。

Patch 版本（x.x.Z）：修復 bug，保持向下兼容。
私有套件版本通常從 0.x 開始，當功能和 API 穩定後再發布 1.0。同時，我會利用 branch-alias 讓 dev-master 分支指向最新的穩定版本。

實務案例：我為公司內部開發的共用套件建立了一個自動發布 pipeline。每當有程式碼 commit 到 main 分支並通過測試後，CI 會自動觸發 build、test、打上 Git tag 並更新 Satis 索引，確保內部所有專案都能一致地使用最新穩定版的套件。

常用的 PHP 性能剖析工具與典型優化手法。

在追求高效能的 PHP 應用程式時，性能剖析和優化是不可或缺的環節。

常用工具：

Xdebug：不僅是強大的調試工具，其內建的 profiler 功能可以生成呼叫圖（call graphs）和火焰圖（flame graphs），精確分析每個函數的執行時間和記憶體消耗。我通常會搭配 KCacheGrind 或 Webgrind 進行視覺化分析。

Blackfire.io：這是一個雲端性能剖析工具，能自動捕捉 CPU、記憶體和 I/O 瓶頸，並提供詳細的報告和建議，尤其與 Laravel 整合效果極佳。

APM 工具 (Application Performance Monitoring)：如 New Relic、Datadog 或 SkyWalking，這些工具用於生產環境的持續監控，能追蹤應用程式的慢查詢、API 延遲、錯誤率等關鍵指標。

Benchmark 工具：例如 Apache Bench (ab) 或 Locust，用於模擬負載測試，評估應用程式在特定併發量下的性能表現。

典型優化手法：

程式碼層面：

避免 N+1 查詢：透過 Eloquent 的 Eager Loading (with()) 預先載入關聯資料，大幅減少資料庫查詢次數。

啟用 Opcache：PHP 內建的 Opcode Cache 可以預編譯 PHP 程式碼，避免每次請求都重新解析，顯著提升性能。

啟用 JIT (Just-In-Time) 編譯器：PHP 8.x 的 JIT 在 CPU 密集型運算中能提供額外的性能提升。

重構迴圈：盡量使用 PHP 內建的 array_map, array_filter, array_reduce 等函數替代複雜的 foreach 迴圈，因為 C 語言實現的內建函數通常更快。

資料庫層面：

索引優化：為經常出現在 WHERE、JOIN、ORDER BY 子句中的欄位建立適當索引。

查詢緩存：利用 Redis 或 Memcached 等記憶體快取服務，緩存頻繁查詢的結果。

分頁查詢優化：針對大型資料集的分頁，避免使用過大的 offset，可結合 WHERE id > last_id 或基於游標的分頁。

架構層面：

PHP-FPM 調校：根據伺服器的 CPU 和記憶體資源，調整 pm.max_children、pm.start_servers 等 PHP-FPM 配置，以最佳化 worker 進程的數量和行為。

異步任務：將耗時的操作（如發送郵件、圖像處理、生成報告）放入隊列（如 Laravel Horizon, RabbitMQ, Kafka）中異步處理，避免阻塞請求。

持續監控與迭代：

設定性能基準線，並在每次優化後進行 A/B 測試，量化優化效果。

利用 APM 工具持續監控生產環境，及早發現潛在的性能回歸。

實務案例：我曾優化一個響應時間高達 500ms 的 API。透過 Blackfire.io 分析，發現主要的瓶頸在於多個獨立的 SQL 查詢。經過重構，改用 prepared statements 並引入 Redis 緩存熱門資料，最終將響應時間降低到 50ms 以內。

框架與實作

在 Laravel/Vue/PHP-FPM/Nginx 的實戰經驗與調校案例。

我擁有豐富的 Laravel/Vue 全端開發經驗，尤其擅長使用這種技術棧來構建高性能的 SaaS 應用程式。典型的架構模式為：Vue.js 作為前端單頁應用（SPA），Laravel 作為後端 API 服務，PHP-FPM 負責處理 PHP 程式碼的執行，Nginx 則作為反向代理伺服器和靜態資源伺服器。

實戰經驗與調校案例：

PHP-FPM 性能調校：

在一個高併發的電商系統中，預設的 PHP-FPM 配置 pm=static (固定 worker 數量) 導致了資源浪費或不足。我將其調整為 pm=dynamic (動態增減 worker)，並根據伺服器的 CPU 核心數和記憶體容量計算出最佳的 pm.max_children (例如 100) 和 pm.start_servers (例如 20)。

計算規則：max_children ≈ (總記憶體 - OS 及其他服務開銷) / 每 PHP 進程平均記憶體消耗。

效果：這項調校使得請求處理時間從 200ms 顯著降低到 80ms。

補充：我還會設定 pm.max_requests (例如 500)，讓 PHP-FPM worker 在處理一定數量請求後自動重啟，以防止潛在的記憶體洩漏問題。

Nginx 調校：

Worker 進程：將 worker_processes 設定為 auto，讓 Nginx 自動偵測 CPU 核心數。worker_connections 則根據伺服器資源設定為 1024 或更高。

靜態資源優化：啟用 gzip 壓縮靜態資產，如 JavaScript、CSS 和圖片，減少網路傳輸量。

FastCGI 配置：正確配置 fastcgi_pass 將 PHP 請求轉發給 PHP-FPM 服務，並優化 fastcgi_buffers 等參數。

Vue.js 路由處理：針對 Vue.js SPA，Nginx 需要配置 try_files $uri $uri/ /index.html;，以確保所有未知路由都能回退到 index.html，讓 Vue Router 接管前端路由，避免 404 錯誤。

Laravel 特定優化：

Laravel Octane：對於極致性能需求，我會考慮使用 Laravel Octane 搭配 Swoole 或 RoadRunner，取代傳統的 PHP-FPM。這能將應用程式常駐記憶體，顯著減少框架啟動時間，提升吞吐量達 30% 或更高。

隊列處理：利用 Laravel Queue 搭配 Redis 或 RabbitMQ 處理耗時任務（如郵件發送、數據匯入），確保 API 響應速度。

快取：積極使用 Laravel 的快取系統（Redis, Memcached）來緩存資料庫查詢結果、配置檔和視圖。

Vue.js 前端優化：

狀態管理：使用 Pinia 或 Vuex 進行應用程式狀態管理，確保組件之間資料流清晰且高效。

組件渲染優化：透過 v-if / v-show 減少不必要的渲染，使用 keep-alive 緩存不活躍組件。

打包優化：使用 Vite 或 Webpack 進行代碼分割（Code Splitting），按需載入組件，減少首次載入時間。

部署策略：

我通常會使用 Laravel Envoy 或 Laravel Forge 等工具來自動化部署流程，並實施藍綠部署（Blue/Green Deployment）策略，確保零 downtime。這意味著新版本部署在一個獨立的環境（綠環境），測試通過後，再將流量切換過去，舊版本（藍環境）則作為備份，以便快速回滾。

整合案例：我曾建立一個企業級 CRM 系統，Laravel 後端負責用戶身份驗證、排隊任務和複雜業務邏輯，Vue 前端透過 Axios 呼叫 RESTful API。Nginx 不僅作為反向代理，還負責處理 CORS (跨域資源共享) 設定。在一次上線後，監測到 PHP-FPM 記憶體洩漏問題，經過分析調整 pm.max_requests 參數，問題得以快速解決。

ORM 與原生 SQL 的取捨與何時用索引、分表或資料去正規化。

在資料庫操作上，ORM（Object-Relational Mapping）和原生 SQL 各有優勢，而索引、分表和去正規化則是優化資料庫性能的重要手段。

ORM 與原生 SQL 的取捨：

ORM 優勢 (如 Laravel Eloquent)：

快速開發：將資料庫操作抽象為物件方法，減少了手寫 SQL 的時間，提高了開發效率。

可讀性與維護性：程式碼通常更易讀、易於理解和維護。

支援關係載入：Eager Loading (with()) 和 Lazy Loading 方便處理資料關聯。

資料庫抽象：方便切換不同的資料庫系統（雖然實際情況中較少發生）。

安全性：ORM 預設使用 Prepared Statements，有效防止 SQL Injection。

原生 SQL 優勢：

精細控制與性能：可以直接編寫最優化的 SQL 語句，沒有 ORM 額外轉換的開銷，在複雜查詢或批次操作上性能通常更高。

複雜查詢：對於高度優化的聚合查詢、複雜子查詢、報表生成等，原生 SQL 更具彈性。

特定資料庫功能：可以利用特定資料庫的獨有功能或語法。

我的取捨策略：
我通常會採用「80/20 法則」：約 80% 的 CRUD 操作和中小型應用會優先使用 ORM 來加速開發。而對於 20% 性能關鍵、複雜或需要精細調優的查詢，我會毫不猶豫地使用原生 SQL（在 Laravel 中通常是透過 DB::raw() 或 DB::select() 等方式）。

實務案例：在 Laravel 專案中，我會將 Eloquent ORM 用於大部分的模型操作和關聯查詢，但在生成複雜的統計報告時，我會直接編寫高效的原生 SQL 語句，以確保性能。

何時用索引、分表或資料去正規化？

1. 何時用索引 (Index)：

用途：主要用於優化資料的讀取速度。

時機：

WHERE 子句：經常出現在 WHERE 條件中的欄位。

JOIN 關聯：用於 JOIN 操作的關聯欄位。

ORDER BY / GROUP BY：用於排序或分組的欄位。

查詢性能瓶頸：當資料庫的慢查詢日誌（slow log）顯示某個查詢耗時超過 100ms 時，就應該考慮為相關欄位添加索引。

複合索引：對於多條件查詢，考慮建立複合索引（欄位順序很重要）。

風險：索引會增加資料庫寫入（INSERT, UPDATE, DELETE）的開銷，因為每次寫入都需要更新索引結構。過多的索引也會佔用儲存空間。需要定期運行 OPTIMIZE TABLE 清理索引碎片。

2. 何時用分表 (Sharding/Partitioning)：

用途：解決單表資料量過大（通常超過千萬行）或寫入吞吐量遇到瓶頸時的擴展性問題。

時機：

水平分表 (Sharding)：當單一表中的資料量達到數千萬甚至上億行，且資料庫的 I/O 成為性能瓶頸時。常見策略是基於 user_id % N 或 order_id % N 將資料分散到多個物理表或資料庫實例上。

垂直分表 (Vertical Partitioning)：當表的欄位過多，且有些欄位非常頻繁被讀取，而有些則較少時，可以將熱資料和冷資料分離到不同的表。

工具：可以透過資料庫自帶的分區功能，或使用 Vitess、ProxySQL 等中間件來管理分表。

風險：分表增加了資料庫操作的複雜性，跨分片的查詢需要額外的聚合服務，並且需要考慮分片鍵的選擇以避免資料熱點。

3. 何時用資料去正規化 (Denormalization)：

用途：透過引入資料冗餘來換取讀取性能的提升，尤其適用於讀多寫少的場景。

時機：

讀多寫少：當某個查詢需要頻繁地 JOIN 多個表才能獲取所需資訊，且這些資訊更新頻率不高時。

計算欄位：將一些經常需要計算的聚合值（例如：訂單總額、用戶發帖數）預先計算好並儲存在表中，避免每次查詢都進行實時計算。

報表生成：為報表系統建立去正規化的資料集（data mart），減少查詢複雜度。

策略：

Stored Generated Columns (MySQL 5.7+): 將計算結果作為一個儲存欄位，資料庫會自動維護。

手動維護：透過應用程式邏輯或觸發器（triggers）來確保冗餘資料的一致性。

風險：資料冗餘意味著需要額外的工作來維護資料一致性。當原始資料更新時，所有冗餘資料都需要同步更新，這會增加寫入操作的複雜度。

實務案例：在一個論壇系統中，為了快速顯示每個用戶的發帖數，我將 post_count 這個聚合欄位去正規化到 users 表中。這樣一來，顯示用戶列表時就不需要與 posts 表進行 JOIN 操作，讀取性能提升了 50% 以上。當用戶發帖時，只需同時更新 posts 表和 users 表中的 post_count 即可。

測試與品質保證

單元測試、整合測試與 contract testing 的實務做法。

為了確保軟體品質，我會結合不同層次的測試策略：單元測試、整合測試和契約測試。

單元測試 (Unit Testing)：

目標：測試應用程式中最小的、可獨立運行的程式碼單元（如一個函數、一個類別的一個方法）是否按預期工作，且與外部依賴隔離。

實務做法：

使用 PHPUnit 作為測試框架。

透過 Mockery 或 PHPUnit 內建的 Mock 物件來模擬外部依賴（如資料庫連線、HTTP 請求、第三方服務），確保測試的獨立性和速度。

我會採用 TDD (Test-Driven Development) 的開發模式，先撰寫測試案例，然後再編寫滿足測試的程式碼。

關注點：覆蓋程式碼的邊界條件（例如：輸入為 null、空陣列、極端值）和錯誤處理邏輯。

案例：測試一個 Service 類別中的商業邏輯，例如計算購物車總價的函數，確保其在不同商品數量、折扣條件下都能返回預期的結果。

整合測試 (Integration Testing)：

目標：測試多個模組或組件之間的協同工作是否正確，包括與資料庫、文件系統、外部 API 等實際依賴的互動。

實務做法：

在 Laravel 專案中，我會利用 Laravel 提供的 HTTP 測試功能（$this->get('/api/users'), $this->post('/api/posts', $data)) 模擬實際的 HTTP 請求。

使用 Laravel Testbench 或在測試環境中設定真實的資料庫（通常是 SQLite in-memory 或一個專用的測試資料庫），在每次測試前運行資料庫遷移（migrations）和填充（seeders），確保測試環境的純淨性。

關注點：測試端到端（E2E）的流程，例如用戶註冊、登錄、創建訂單等。

案例：測試一個 API 端點，發送 HTTP 請求，驗證資料庫中是否正確插入資料，以及 API 返回的 JSON 結構是否符合預期。

契約測試 (Contract Testing)：

目標：確保服務的消費者（Consumer）和提供者（Provider）之間關於 API 介面、資料格式的「契約」是保持一致的，特別是在微服務架構中，可以防止服務間的 breaking changes。

實務做法：

我會使用 Pact 框架（或類似工具）。消費者會定義它對提供者的期望（例如 API 路徑、HTTP 方法、請求參數、預期響應），生成一個 Pact 文件。

提供者會使用這個 Pact 文件來驗證自己的 API 實現是否符合消費者的期望。

工具：前端 Vue 應用可以使用 Pact-js 定義預期響應，後端 Laravel 應用則可以使用 Pact-php 來驗證。

整合到 CI/CD：將契約測試整合到 CI/CD pipeline 中，確保在部署前就能發現不兼容的 API 變更。

案例：在一個微服務架構中，前端 Vue 應用是某個後端訂單服務的消費者。前端定義了獲取訂單列表的 API 契約。當後端開發者修改訂單 API 時，契約測試會在 CI 過程中運行，如果修改導致契約不符，則會立即報錯，阻止部署，避免影響前端應用。

整體策略與目標：

我的目標是達到至少 90% 的程式碼覆蓋率，並使用 Codecov 等工具來監控和報告覆蓋率。對於大型專案，我還會結合 Feature Flags (功能開關) 進行漸進式測試，在生產環境中逐步釋出新功能，同時監控其穩定性。

CI/CD pipeline 範例：從 commit 到部署的關鍵步驟與 rollback 策略。

一個健壯的 CI/CD (Continuous Integration/Continuous Delivery) pipeline 是實現快速、可靠部署的關鍵。我通常會使用 GitHub Actions 或 GitLab CI 來構建我的 pipeline。

CI/CD Pipeline 範例 (以 GitHub Actions 為例)：

Commit/Push 事件觸發：

當開發者將程式碼 commit 並 push 到 Git 倉庫（例如 main 或 feature 分支）時，CI/CD workflow 會自動觸發。

Build (構建)：

安裝依賴：執行 composer install --no-dev --optimize-autoloader 安裝後端 PHP 依賴。

前端構建：如果專案包含前端應用（如 Vue.js），執行 npm install 或 yarn install，然後執行 npm run build 或 yarn build 生成前端靜態資源。

Test (測試)：

單元/整合測試：運行 PHPUnit 測試 (./vendor/bin/phpunit)，確保程式碼邏輯正確。

靜態分析：運行 PHP_CodeSniffer (phpcs) 檢查程式碼風格，以及 PHPStan/Psalm 進行靜態型別檢查，發現潛在錯誤。

Lint/Security (代碼檢查與安全掃描)：

前端 Lint：運行 ESLint 檢查 JavaScript/Vue 程式碼風格。

安全掃描：運行 sensiolabs/security-checker 或 roave/security-advisories 檢查 Composer 依賴中是否存在已知漏洞。

Deploy (部署)：

條件判斷：通常只有當程式碼 push 到 main 分支，且所有前面的步驟都成功時，才會觸發部署。

部署腳本：

SSH 連線到目標伺服器。

從 Git 倉庫拉取最新程式碼 (git pull origin main)。

安裝生產環境依賴 (composer install --no-dev --optimize-autoloader)。

運行資料庫遷移 (php artisan migrate --force)。

清除和快取配置 (php artisan config:cache, php artisan route:cache, php artisan view:cache)。

零停機部署 (Zero-Downtime Deployment)：使用工具如 Laravel Envoy 搭配 Atomic Deployment (透過符號連結切換新舊版本) 或 Capistrano，將新版本部署到一個新的目錄，然後更新 Nginx 的根目錄符號連結，實現幾乎無感知的版本切換。

Post-Deploy (部署後)：

煙霧測試 (Smoke Test)：執行簡單的 HTTP 請求（例如 curl https://your-app.com/health）檢查應用程式的基本功能是否正常。

通知：向 Slack 或其他協作工具發送部署成功的通知。

Rollback 策略：
程式碼回滾：
Git Revert：如果部署後發現嚴重的程式碼 bug，最直接的方式是在 Git 歷史中執行 git revert <commit_hash>，創建一個新的 commit 來撤銷問題 commit 的修改，然後重新觸發 CI/CD 部署。
Git Tag：為每個成功部署的版本打上 Git Tag，當需要回滾時，可以直接部署到上一個穩定的 Tag 版本。
資料庫回滾：
如果資料庫遷移（migrations）導致問題，則需要運行 php artisan migrate:rollback 來回滾最新的遷移。但這只適用於沒有不可逆變更（如刪除欄位或表）的遷移。對於有不可逆變更的遷移，需要提前準備好資料庫備份和恢復方案。
藍綠部署 (Blue/Green Deployment)：
這是最安全的部署和回滾策略。在新的版本部署到「綠」環境時，「藍」環境（舊版本）仍然保持運行。一旦發現問題，可以立即將流量從「綠」環境切換回「藍」環境，實現快速回滾，幾乎沒有用戶影響。
自動化回滾：
設定監控指標（如生產環境的錯誤率超過 5%、響應時間急劇上升）。當這些指標觸發閾值時，自動觸發回滾到上一個已知穩定的版本。
實務案例：我曾因為一個資料庫遷移 bug 導致生產環境部分功能失效。由於我們採用了零停機部署，且有明確的 Rollback 策略，在監控系統發出告警後，團隊迅速判斷問題，並在 5 分鐘內將服務回滾到上一個穩定版本，大大減少了用戶受影響的時間。

安全與營運 (續)

量化可用性與告警策略：SLA、指標與 incident handling 流程。

在生產環境中，量化服務可用性並建立健全的告警與事件處理機制至關重要，以確保服務穩定運行並快速響應問題。

服務等級協議 (SLA - Service Level Agreement)：

定義：我通常會設定服務的目標可用性，例如 99.9% uptime。

計算：可用性 = (總時間 - downtime) / 總時間。

99.9% uptime 意味著每月允許的停機時間約為 43 分鐘。

99.99% uptime 則每月約為 4 分鐘。

SLA 是與業務部門或客戶承諾的服務品質標準，所有營運和開發策略都應圍繞此目標。

關鍵指標 (Metrics) 與監控：
為了達成 SLA，我們需要持續監控一系列關鍵性能指標 (KPIs)：

Apdex 分數 (Application Performance Index)：衡量用戶對應用響應速度的滿意度。例如，設定目標為 90% 的請求響應時間在 200ms 以內。

錯誤率 (Error Rate)：目標是將生產環境的錯誤率控制在 1% 以下。特別關注 HTTP 5xx 錯誤。

資源利用率：監控伺服器的 CPU 使用率、記憶體使用率、磁碟 I/O 和網路流量，目標通常是維持在 80% 以下，留有足夠的餘裕空間。

資料庫指標：慢查詢數量、連線數、TPS (Transactions Per Second) 等。

隊列深度：監控異步任務隊列的長度，防止任務堆積。

工具：我會使用 Prometheus 收集這些指標，並透過 Grafana 進行視覺化。對於雲端服務，Datadog、New Relic 等 APM 工具提供更全面的監控與告警功能。

告警策略 (Alerting Strategy)：

閾值設定：根據上述指標設定合理的告警閾值。例如：

CPU 使用率連續 5 分鐘超過 90%。

錯誤率在 1 分鐘內持續超過 5%。

Apdex 分數在 5 分鐘內低於 0.7。

告警通道：將告警發送到不同的通道，例如：

即時通訊：發送到 Slack、Microsoft Teams 的專用告警頻道。

電子郵件：發送給相關團隊成員。

電話/簡訊：對於 P1 (高嚴重性) 事件，使用 PagerDuty 等 On-Call 工具觸發電話或簡訊，確保值班人員被喚醒。

告警層級：區分不同的告警嚴重性（Warning, Critical），避免「告警疲勞」。

事件處理流程 (Incident Handling Process)：
一個清晰定義的事件處理流程是快速恢復服務的關鍵。

偵測 (Detection)：

監控系統觸發告警，自動發送到相關渠道（如 Slack、PagerDuty）。

人工監控儀表板或接收用戶報告。

評估 (Assessment)：

On-Call SRE 或工程師立即響應。

檢查日誌（透過 ELK Stack - Elasticsearch, Logstash, Kibana 或 Loki/Grafana），確認問題現象和範圍。

分類嚴重性：

P1 (Critical)：服務完全中斷，所有用戶受影響。

P2 (High)：部分服務受影響，大量用戶受影響。

P3 (Medium)：服務有性能下降或小部分用戶受影響。

P4 (Low)：輕微問題，不影響核心功能。

響應 (Response)：

隔離問題：如果可能，隔離受影響的組件或服務，防止問題擴散（例如：擴展受影響的服務實例，或將流量重新路由到健康實例）。

恢復服務：優先恢復服務，而不是立即解決根本原因。例如：重啟服務、回滾版本、調整配置、增加資源。

溝通：向內部團隊和受影響用戶發送狀態更新。

恢復 (Recovery)：

問題解決後，確認服務完全恢復，所有監控指標恢復正常。

移除任何臨時的緩解措施。

事後檢討 (Post-Mortem / RCA - Root Cause Analysis)：

召集相關團隊進行不責怪的事後檢討會議。

深入分析事件發生的根本原因。

識別可以改進的流程、工具或系統設計。

更新 Runbook 或操作手冊，增加未來預防措施。

學習與改進 (Learning & Improvement)：

實施事後檢討中提出的改進措施，避免相同事件再次發生。

實務案例：我曾處理一個生產環境的 DDoS 攻擊事件。透過 Cloudflare 的 WAF 和速率限制功能，我們在偵測到流量異常的第一時間進行了流量過濾和限制。同時，由於預先配置了自動擴展策略，應用服務器得以快速擴展。整個過程從偵測到服務恢復到正常水平，在 10 分鐘內完成，將對用戶的影響降到最低。事後，我們根據 Cloudflare 的日誌分析了攻擊模式，進一步強化了防禦規則。

系統設計題示例

題目範例：設計一個支援每分鐘百萬請求的訂單系統 API。

需求分析：

核心功能：訂單創建（寫重）、訂單查詢（讀重，需支援多條件）、訂單更新（狀態更新）、支付整合。

非功能需求：

高併發：每分鐘 100 萬請求 (~16.7k RPS)，峰值可能達到 2x (~33k RPS)。

高可用性：多可用區部署，服務不中斷。

低延遲：訂單創建/查詢響應時間 < 100ms。

資料一致性：核心交易（訂單創建、支付）需強一致性，非核心可最終一致性。

可擴展性：能水平擴展以應對業務增長。

安全性：API 身份驗證、授權、防刷。

系統架構設計：

API Gateway / 負載均衡 (Load Balancer)：

Nginx / Haproxy：作為最前端的負載均衡器，將流量分發到後端多個 API 服務實例。

API Gateway (如 Kong, Apigee)：提供統一入口，負責身份驗證、限流、熔斷、日誌、監控、SSL 終止等功能。

CDN (內容分發網路)：若有靜態內容，可利用 CDN 加速分發。

應用服務層 (Application Service Layer)：

技術棧：Laravel API + Laravel Octane (基於 Swoole/RoadRunner)，或多個 PHP-FPM 實例。

部署：部署在多個可用區（Multi-AZ），透過 Kubernetes 進行容器化部署和自動擴展 (Horizontal Pod Autoscaler, HPA)，基於 CPU 利用率或 RPS 擴展 Pod 數量。

異步處理：將所有非即時、耗時的任務（如發送訂單確認郵件、更新庫存、日誌記錄）放入消息隊列（Kafka/RabbitMQ）中異步處理，避免阻塞訂單創建流程。

資料庫選型與策略：

核心訂單資料庫：

選型：MySQL (InnoDB 引擎) 或 PostgreSQL，支援 ACID 事務，成熟穩定。

讀寫分離：主從複製 (Master-Slave Replication)，寫入主庫，讀取從庫。確保從庫延遲 (replication lag) 極低。

分庫分表 (Sharding)：為應對百萬級別的寫入和查詢，必須進行水平分表。

分片鍵 (Sharding Key)：選擇 user_id 或 order_id 作為分片鍵。例如，根據 order_id % N 將訂單資料分散到 N 個資料庫實例或表中。

一致性哈希：考慮使用一致性哈希，以便於未來彈性增減分片。

工具：可使用中間件如 ProxySQL、Vitess 或應用層自行實現分片邏輯。

索引設計：

訂單表：主鍵 order_id。複合索引 (user_id, status, created_at) 用於常用查詢。

訂單商品表：主鍵 item_id，索引 order_id。

針對 JSON 欄位（若有）可使用 GIN/B-tree 索引。

定期分析慢查詢日誌，優化索引。

非核心資料庫：

日誌/分析：Elasticsearch (ELK Stack) 或 MongoDB，用於儲存訂單操作日誌、用戶行為分析等非結構化或半結構化資料。

緩存資料庫：Redis 或 Memcached。

緩存策略 (Caching Strategy)：

記憶體緩存 (Redis)：

熱門訂單資料：緩存頻繁查詢的訂單詳情、用戶最近訂單等。設定合適的 TTL (Time-To-Live)，例如 5 分鐘。

寫穿 (Write-Through)：在資料寫入資料庫後，同步更新緩存。

讀穿 (Read-Through)：讀取請求先查詢緩存，如果緩存未命中 (Cache Miss)，則從資料庫讀取並更新緩存。

避免緩存穿透 (Cache Penetration)：對於查詢不到的資料，也存入一個短時間的空值標記，或使用布隆過濾器 (Bloom Filter) 預先判斷請求的資料是否存在。

OPcache：PHP 內建的 Opcode Cache 必須啟用。

消息隊列 (Message Queue)：

目的：解耦系統組件，異步處理，削峰填谷。

選型：Kafka 或 RabbitMQ。

應用場景：

訂單創建：當訂單主體成功寫入資料庫後，發送 order_created 事件到 Kafka。下游服務（庫存服務、支付服務、通知服務、日誌服務）異步消費此事件進行後續處理。

支付結果：支付網關回調後，發送支付結果事件。

庫存扣減：預扣庫存可同步處理，實際扣減可異步處理。

交易一致性：對於涉及多個服務的複雜交易，可考慮使用 Saga 模式 來保證最終一致性。

安全機制：

身份驗證與授權：使用 JWT (JSON Web Token) 或 OAuth 2.0 進行 API 身份驗證。Laravel Passport/Sanctum。

速率限制 (Rate Limiting)：透過 API Gateway 或 Redis Lua 腳本實現限流，例如每個用戶每秒 10 個請求，防止惡意刷單或 DDoS 攻擊。

防火牆與 WAF (Web Application Firewall)：保護應用免受常見 Web 攻擊。

HTTPS：所有 API 請求都必須使用 HTTPS。

監控與告警 (Monitoring & Alerting)：

指標：RPS (Requests Per Second)、API 響應延遲 (p95, p99)、錯誤率、CPU/記憶體/網路 I/O、資料庫慢查詢、隊列深度。

工具：Prometheus + Grafana，配合 Alertmanager 進行告警。APM 工具如 Datadog 或 New Relic。

日誌：使用 ELK Stack (Elasticsearch, Logstash, Kibana) 或 Loki/Grafana Loki 收集和分析所有服務的日誌。

備援與高可用性 (Backup & High Availability)：

多可用區部署：所有核心服務和資料庫都部署在至少兩個可用區，實現冗餘。

資料庫備份與恢復：定期全量備份，增量備份，並測試恢復流程。

資料庫故障轉移 (Failover)：主從資料庫自動切換機制。

應用服務容錯：應用服務的熔斷器 (Circuit Breaker) 和重試機制 (Exponential Backoff)，避免級聯失敗。

可擴展性與操作性 Trade-offs：

可擴展性：水平擴展（sharding 資料庫、增加應用 Pods）是處理百萬級請求的必然選擇。

Trade-off：資料庫分片增加了系統的複雜度，尤其是跨分片的聚合查詢和事務處理會更具挑戰性，可能需要引入聚合服務層。

操作性 (Operability)：

Trade-off：引入 Kafka、Kubernetes 等分散式組件會顯著增加系統的運維複雜度。需要專門的 SRE 團隊，並投入資源在自動化部署、監控和故障排除上。

解決方案：在雲端環境中（如 AWS, GCP, Azure），可以優先考慮使用託管服務（Managed Services），例如 Amazon RDS for MySQL、Amazon MSK for Kafka、Google Kubernetes Engine (GKE) 等，以減少運維負擔，將精力集中在業務邏輯上。

實作或白板題示例

題目範例 A：寫一個安全的檔案上傳 API，包含驗證、病毒掃描整合、儲存與過期清理流程。

以下是在 Laravel 框架下實現這個安全檔案上傳 API 的程式碼範例。假設我們將檔案儲存到 AWS S3，並整合 ClamAV 進行病毒掃描。

// app/Http/Controllers/FileUploadController.php
<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use Illuminate\Support\Facades\Storage;
use Symfony\Component\Process\Process; // 用於執行外部命令，如 ClamAV
use App\Jobs\ExpireFile; // 引入排程任務

class FileUploadController extends Controller
{
    /**
     * 處理安全的檔案上傳請求。
     *
     * @param  \Illuminate\Http\Request  $request
     * @return \Illuminate\Http\JsonResponse
     */
    public function upload(Request $request)
    {
        // 1. 驗證：檢查檔案是否存在、類型、大小
        // - required: 必須存在
        // - file: 確保是上傳的檔案
        // - mimes:pdf,jpg,png: 限制檔案類型為 PDF, JPG, PNG
        // - max:10240: 限制檔案大小最大為 10MB (10240 KB)
        $request->validate([
            'file' => 'required|file|mimes:pdf,jpg,png|max:10240',
        ]);

        $file = $request->file('file');
        $originalName = $file->getClientOriginalName(); // 獲取原始檔名

        // 2. 儲存檔案到 S3
        // 'uploads' 是 S3 儲存桶中的子目錄
        // 's3' 是 config/filesystems.php 中定義的 disk
        $path = $file->store('uploads', 's3'); 

        // 3. 病毒掃描：整合 ClamAV
        // ClamAV 通常安裝在伺服器本地，我們需要將上傳的臨時檔案路徑傳給它
        // 注意：在生產環境中，ClamAV 掃描可能需要獨立的服務或非同步處理，避免阻塞 API 響應。
        // 這裡為簡化白板題，假設同步執行。
        $tempPath = $file->path(); // 獲取上傳檔案的臨時路徑

        // 執行 clamscan 命令。--no-summary 減少輸出，只關注病毒檢測結果
        $process = new Process(['clamscan', '--no-summary', $tempPath]);
        $process->run();

        // 檢查 ClamAV 執行是否成功，並且輸出中不包含 "OK" (表示沒有病毒)
        if (!$process->isSuccessful() || strpos($process->getOutput(), 'OK') === false) {
            // 如果掃描失敗或檢測到病毒，則從 S3 刪除已上傳的檔案
            Storage::disk('s3')->delete($path);
            \Log::warning("Virus detected or scan failed for file: {$originalName}, path: {$path}. Output: " . $process->getOutput());
            return response()->json(['error' => 'Virus detected or scan failed'], 400);
        }

        // 4. 過期清理流程：使用 Laravel Queue Job 排程清理
        // 建立一個 Job 並將其分派到隊列中，設定 7 天後執行
        ExpireFile::dispatch($path)->delay(now()->addDays(7));

        // 5. 返回成功響應
        return response()->json([
            'message' => 'File uploaded successfully',
            'path' => $path,
            'name' => $originalName,
        ], 201);
    }
}

// app/Jobs/ExpireFile.php
<?php

namespace App\Jobs;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Bus\Dispatchable;
use Illuminate\Queue\InteractsWithQueue;
use Illuminate\Queue\SerializesModels;
use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Facades\Log; // 引入 Log Facade

class ExpireFile implements ShouldQueue
{
    use Dispatchable, InteractsWithQueue, Queueable, SerializesModels;

    protected $path; // 儲存檔案在 S3 上的路徑

    /**
     * 建立一個新的 Job 實例。
     *
     * @param string $path 檔案在 S3 上的路徑
     * @return void
     */
    public function __construct(string $path)
    {
        $this->path = $path;
    }

    /**
     * 執行 Job。
     * 該方法會在延遲時間過後，由隊列 Worker 執行。
     *
     * @return void
     */
    public function handle(): void
    {
        try {
            // 從 S3 刪除指定路徑的檔案
            Storage::disk('s3')->delete($this->path);
            Log::info("Expired file deleted successfully: " . $this->path);
        } catch (\Exception $e) {
            // 記錄刪除失敗的錯誤，方便追蹤
            Log::error("Failed to delete expired file: " . $this->path . " Error: " . $e->getMessage());
            // 如果需要，可以重新將此 Job 推入隊列進行重試
            // throw $e; 
        }
    }
}

評分重點：

正確性與安全性：

驗證：MIME 類型檢查、檔案大小限制是防止惡意檔案上傳的第一道防線。

病毒掃描：整合外部病毒掃描工具（ClamAV）是關鍵的安全措施。

異步刪除：使用隊列 Job 進行過期清理，避免阻塞主應用程式，同時確保刪除邏輯的可靠性。

邊界條件處理：

無檔案、超大檔案：$request->validate 會自動拋出異常並返回 JSON 錯誤響應。

掃描失敗/檢測到病毒：立即從儲存服務中刪除已上傳的檔案，避免污染。

刪除失敗：Job 中的 try-catch 確保刪除失敗時有錯誤日誌，可根據需求決定是否重試。

錯誤處理：提供清晰的 JSON 錯誤回應訊息。隊列 Job 失敗應有日誌記錄。

可測試性：

FileUploadController 可透過 Mock Storage Facade 和 Process 類來測試。

ExpireFile Job 也可以獨立測試，Mock Storage Facade。

思路流程：

先驗證：確保檔案符合基本要求。

後掃描：確認檔案安全無毒。

再儲存：將安全檔案存入持久化儲存。

排程刪除：確保檔案生命週期管理。
這個流程確保了在每個環節都進行了安全性檢查，並且將耗時或非即時的操作（如清理）異步化，提升了 API 的響應效率。

題目範例 B：給一段 buggy 的 PHP 程式碼，要求找到性能瓶頸並重構。

原始 Buggy 程式碼 (N+1 問題)：

// 原碼：假設這是某個控制器或服務中的函數
// 目標：獲取指定用戶及其所有訂單，以及每個訂單的商品詳情

<?php
function getUserOrders($userId) {
    // 1. 查詢用戶
    $user = DB::table('users')->where('id', $userId)->first();

    // 如果用戶不存在，這裡會導致 $user 為 null，後續可能拋錯
    if (!$user) {
        return null; // 簡單處理，實際會拋出 HttpException 或返回 404
    }

    // 2. 查詢用戶的所有訂單
    $orders = DB::table('orders')->where('user_id', $userId)->get();

    // 3. 遍歷每筆訂單，查詢其包含的商品詳情
    // 這就是典型的 N+1 問題所在！
    foreach ($orders as $order) {
        $items = DB::table('order_items')->where('order_id', $order->id)->get();
        $order->items = $items; // 將商品詳情附加到訂單物件上
    }

    return ['user' => $user, 'orders' => $orders];
}

問題分析與性能瓶頸：

N+1 查詢問題：

這是最主要的性能瓶頸。首先，我們執行 1 次查詢來獲取用戶。然後，執行 1 次查詢來獲取該用戶的所有訂單。接下來，對於每一筆訂單，我們又執行了 1 次查詢來獲取其商品詳情。

如果一個用戶有 100 筆訂單，這個函數將總共執行 1 (用戶) + 1 (所有訂單) + 100 (每筆訂單的商品) = 102 次資料庫查詢。查詢次數隨著訂單數量線性增長，在高併發或訂單量大的情況下，會迅速壓垮資料庫。

安全性問題：

原始程式碼使用了 DB::table()，雖然 Laravel 查詢構建器會自動處理參數綁定，但在某些非常規使用場景下仍有 SQL Injection 風險。使用 Eloquent ORM 可以更好地規範化操作。

錯誤處理不足：

如果 $userId 對應的用戶不存在，$user 將為 null，但程式碼沒有明確的錯誤處理，可能會導致後續邏輯錯誤或產生難以理解的異常。

可讀性與維護性：

將關聯資料的載入邏輯寫在迴圈內，使得程式碼意圖不夠清晰，維護起來也相對麻煩。

重構後的程式碼 (使用 Eloquent ORM 和 Eager Loading)：

為了更好地重構，我們需要假設有以下 Eloquent 模型及其關聯：

// app/Models/User.php

<?phpnamespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\HasMany;

class User extends Model
{
    // ... 其他屬性

    /**
     * 一個用戶有多個訂單。
     */
    public function orders(): HasMany
    {
        return $this->hasMany(Order::class);
    }
}

// app/Models/Order.php
<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;
use Illuminate\Database\Eloquent\Relations\HasMany;

class Order extends Model
{
    // ... 其他屬性

    /**
     * 一個訂單屬於一個用戶。
     */
    public function user(): BelongsTo
    {
        return $this->belongsTo(User::class);
    }

    /**
     * 一個訂單有多個商品項。
     */
    public function items(): HasMany
    {
        return $this->hasMany(OrderItem::class);
    }
}

// app/Models/OrderItem.php
<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Model;
use Illuminate\Database\Eloquent\Relations\BelongsTo;

class OrderItem extends Model
{
    // ... 其他屬性

    /**
     * 一個訂單商品項屬於一個訂單。
     */
    public function order(): BelongsTo
    {
        return $this->belongsTo(Order::class);
    }
}

// 重構後的函數：假設在一個 Service 或 Controller 中
<?php

namespace App\Services; // 或 App\Http\Controllers

use App\Models\User;
use App\Models\Order;
use Illuminate\Support\Facades\Log;
use Illuminate\Database\Eloquent\ModelNotFoundException; // 引入 ModelNotFoundException

class OrderService
{
    /**
     * 獲取指定用戶及其所有訂單，包含每個訂單的商品詳情。
     *
     * @param int $userId
     * @return array
     * @throws \Exception 如果獲取訂單失敗
     */
    public function getUserOrders(int $userId): array
    {
        try {
            // 1. 查詢用戶，如果找不到則拋出 ModelNotFoundException
            // User::findOrFail() 會自動處理用戶不存在的情況
            $user = User::findOrFail($userId);

            // 2. 查詢用戶的所有訂單，並使用 Eager Loading 預加載關聯的 'items'
            // Order::with('items') 會在查詢訂單時，透過 JOIN 或額外的查詢一次性獲取所有訂單的商品項
            // 解決了 N+1 問題
            $orders = Order::with('items')
                ->where('user_id', $userId)
                ->get();

            return ['user' => $user, 'orders' => $orders];
        } catch (ModelNotFoundException $e) {
            // 處理用戶不存在的情況，可以返回 404 錯誤給前端
            Log::info("User with ID {$userId} not found.", ['exception' => $e]);
            // 這裡可以選擇拋出一個自定義的應用級別異常，或直接返回一個空的/錯誤響應
            throw new \Illuminate\Http\Exceptions\HttpResponseException(
                response()->json(['message' => 'User not found'], 404)
            );
        } catch (\Exception $e) {
            // 捕獲其他所有異常，記錄日誌並拋出通用錯誤
            Log::error("Failed to fetch orders for user ID {$userId}. Error: " . $e->getMessage(), ['exception' => $e]);
            throw new \Exception('Failed to fetch orders due to an internal server error.', 500);
        }
    }
}

改進與優化：

解決 N+1 查詢：

透過 Order::with('items') 使用了 Eloquent 的 Eager Loading (預加載) 功能。這將會執行 2 次查詢：

查詢所有符合條件的訂單：SELECT * FROM orders WHERE user_id = ?

查詢這些訂單的所有商品項：SELECT * FROM order_items WHERE order_id IN (?, ?, ...)

無論有多少筆訂單，查詢次數都固定為 2 次（或者說 1 (user) + 2 (orders with items) = 3 次總查詢），極大地減少了資料庫負載，顯著提升性能。

增強健壯性與錯誤處理：

使用 User::findOrFail($userId) 替代 DB::table(...)->first()。如果找不到用戶，findOrFail 會自動拋出 ModelNotFoundException，可以更優雅地處理 404 錯誤，而不是讓程式碼因為 $user 為 null 而崩潰。

增加了 try-catch 區塊來捕獲 ModelNotFoundException 和其他通用 \Exception，並記錄詳細日誌 (Log::error)，提高了程式碼的健壯性和可偵錯性。

提高程式碼可讀性與維護性：

透過 Eloquent 模型及其關聯的定義，程式碼的意圖更清晰，更容易理解資料結構和關聯。

將業務邏輯封裝在 Service 類別中，遵循了 SRP (單一職責原則)。

安全性：

Eloquent ORM 和查詢構建器底層都使用 Prepared Statements，進一步增強了 SQL Injection 的防禦能力。

評分重點：

識別瓶頸：能否準確指出 N+1 查詢問題是核心。

重構方案：是否能提出有效的解決方案，例如使用 Eager Loading。

錯誤處理：是否考慮了邊界條件（如用戶不存在）並進行了恰當的錯誤處理和日誌記錄。

程式碼品質：使用 Eloquent ORM 提高了程式碼的可讀性、可維護性和安全性。

思路流程：展示了從問題分析到解決方案設計，再到具體程式碼實現的完整思考過程。

羅培宸的技術筆記：從面試戰場到 AI 實戰

2025年10月28日星期二

PHP 全端工程師面試指南：深度解析與實戰經驗分享

PHP 全端工程師面試指南：深度解析與實戰經驗分享

PHP 與生態

你常用哪個 PHP 版本與理由；遇到相容性問題怎麼解決？

Composer 套件管理策略、私有套件的發布與版本策略。

常用的 PHP 性能剖析工具與典型優化手法。

框架與實作

在 Laravel/Vue/PHP-FPM/Nginx 的實戰經驗與調校案例。

ORM 與原生 SQL 的取捨與何時用索引、分表或資料去正規化。

何時用索引、分表或資料去正規化？

測試與品質保證

單元測試、整合測試與 contract testing 的實務做法。

CI/CD pipeline 範例：從 commit 到部署的關鍵步驟與 rollback 策略。

安全與營運 (續)

量化可用性與告警策略：SLA、指標與 incident handling 流程。

系統設計題示例

題目範例：設計一個支援每分鐘百萬請求的訂單系統 API。

實作或白板題示例

題目範例 A：寫一個安全的檔案上傳 API，包含驗證、病毒掃描整合、儲存與過期清理流程。

題目範例 B：給一段 buggy 的 PHP 程式碼，要求找到性能瓶頸並重構。

沒有留言:

張貼留言

熱門文章

搜尋此網誌

2025年10月28日 星期二

PHP 全端工程師面試指南：深度解析與實戰經驗分享

PHP 全端工程師面試指南：深度解析與實戰經驗分享

PHP 與生態

你常用哪個 PHP 版本與理由；遇到相容性問題怎麼解決？

Composer 套件管理策略、私有套件的發布與版本策略。

常用的 PHP 性能剖析工具與典型優化手法。

框架與實作

在 Laravel/Vue/PHP-FPM/Nginx 的實戰經驗與調校案例。

ORM 與原生 SQL 的取捨與何時用索引、分表或資料去正規化。

何時用索引、分表或資料去正規化？

測試與品質保證

單元測試、整合測試與 contract testing 的實務做法。

CI/CD pipeline 範例：從 commit 到部署的關鍵步驟與 rollback 策略。

安全與營運 (續)

量化可用性與告警策略：SLA、指標與 incident handling 流程。

系統設計題示例

題目範例：設計一個支援每分鐘百萬請求的訂單系統 API。

實作或白板題示例

題目範例 A：寫一個安全的檔案上傳 API，包含驗證、病毒掃描整合、儲存與過期清理流程。

題目範例 B：給一段 buggy 的 PHP 程式碼，要求找到性能瓶頸並重構。

沒有留言:

張貼留言

熱門文章

2025年10月28日星期二