算法审查：工程自查清单

引言：“隐藏”的崩溃

大多数 Bug 导致报错，而算法 Bug 导致 全线崩溃。 一段在 10 個測試數據上跑得飛快的邏輯，在遇到 10,000 個生產數據時可能需要 10 分鐘。作為開發者或審查者，妳需要在代碼審查 (Code Review) 中培養識別這些模式的“火眼金睛”。

審查者檢查清單

1. 嵌套循環陷阱 ($O(N^2)$)

• 模式： 在一個 for 循環內部嵌套另一個對同一列表的 for 循環。
• 建議： “我們能不能把內層循環換成 哈希表 查找，把複雜度降到 $O(N)$？”
• 範例： 查重或合併兩個列表。

2. 字符串拼接陷阱

• 模式： 在循環中使用 str += "..." 構建長字符串。
• 風險： 在許多語言（如 Java 或 Python）中，字符串是不可變的。每次拼接都會創建新對象，導致 $O(N^2)$ 的內存拷貝。
• 建議： “使用 StringBuilder 或最後一次性 join 數組。”

3. 無界遞歸

• 模式： 沒有明確深度限制的深層遞歸。
• 風險： 棧溢出 (Stack Overflow)。
• 建議： “輸入深度有限制嗎？如果沒有，能不能改用 迭代 加棧的方式實現？”

4. 數據庫 N+1 查詢

• 模式： 在循環內部調用數據庫查詢。
• 建議： “進行批量操作！先收集所有 ID，然後用一條 WHERE id IN (...) 語句解決。”

5. 過度排序

• 模式： 為了獲取前 3 名而對整個列表進行排序。
• 建議： “使用 小頂堆 或 快速選擇 在 $O(N)$ 時間內獲取 Top K。”

開發者的自我修正

在提交 PR 之前，問問自己：

• “如果 N 是 100,000 會發生什麼？” (可擴展性)
• “這段邏輯是確定性的嗎？” (可靠性)
• “我使用了正確的數據結構嗎？” (效率)

典型業務場景

• ✅ CSV 導出： 導出 100 萬行時，不要在內存中構建整個數組。請使用 流式傳輸 (Streaming)。
• ✅ 權限校驗： 不要嵌套循環對比每個用戶和每個角色。請使用 位圖 (Bitmask) 或 Set 集合。

小結：一句话记住它

“代碼審查不僅僅是語法檢查，更是對系統未來的保護。一份算法清單能確保妳今天寫下的代碼，不會變成妳明天要修的線上事故。”