Code Review 流程
當執行程式碼審查時，請遵循以下步驟：
1. 取得變更內容
根據使用者需求執行適當的 git 指令：
- •
git diff— 查看未暫存的變更 - •
git diff --staged— 查看已暫存（即將提交）的變更
2. 審查重點（依優先順序）
🔴 邏輯衝突與錯誤（最高優先）
- •變數/函數在修改後是否與其他地方的使用產生衝突
- •條件判斷邏輯是否正確（特別注意邊界條件）
- •資料流是否完整，有無遺漏的狀態更新
- •非同步操作的順序與錯誤處理
- •型別不匹配或隱性型別轉換問題
🟠 潛在風險
- •是否引入安全漏洞（XSS、SQL Injection、Command Injection 等）
- •效能問題（N+1 查詢、不必要的重複運算、記憶體洩漏）
- •錯誤處理是否完善
- •邊界情況是否處理
🟡 程式碼品質
- •命名是否清晰表達意圖
- •是否違反 DRY 原則（重複程式碼）
- •函數/元件職責是否單一
- •是否有未使用的變數或 import
🟢 風格與一致性
- •是否符合專案既有的程式碼風格
- •縮排與格式是否一致
3. 輸出格式
請使用以下格式輸出審查結果（使用繁體中文）：
markdown
## 📋 Code Review 摘要 **審查範圍：** [描述變更涵蓋的檔案/功能] **整體評估：** ✅ 可合併 / ⚠️ 建議修改 / ❌ 需要修正 --- ### 🔴 必須修正（Critical） #### 問題 1：[問題標題] - **檔案：** `path/to/file.ts:行號` - **問題：** [描述問題] - **影響：** [說明可能造成的後果] - **建議修正：** ```typescript // 修正後的程式碼
🟠 建議改善（Warning）
[同上格式]
🟢 良好實踐（Positive）
- •[列出值得肯定的程式碼實踐]
code
## 4. 特別注意事項 - 專注於這次變更本身，不要對未修改的程式碼提出建議 - 如果發現變更可能影響其他未修改的程式碼，明確指出關聯性 - 對於不確定的問題，使用「可能」、「建議確認」等措辭 - 提供具體可執行的修正建議，而非模糊的指導