本文記錄了一份通用的代碼審查清單，可結合實際項目調整。

代碼審查是保障代碼質量的重要環節，以下是一份通用的代碼審查清單，涵蓋功能、可讀性、安全性、性能、可維護性等多個維度，可根據具體項目場景（如前端、后端、移動端等）靈活調整：

一、功能正確性

1. 代碼是否完全實現了需求文檔中的功能點？是否覆蓋了所有場景（包括正常流程、邊界條件、異常情況）？
2. 邏輯是否嚴謹？是否存在邏輯漏洞（如條件判斷遺漏、循環邊界錯誤等）？
3. 單元測試/集成測試是否覆蓋關鍵邏輯？測試用例是否合理（包括正向、反向、邊界值測試）？
4. 與其他模塊/系統的交互是否正確？接口調用參數、返回值處理是否符合約定？

二、代碼可讀性

1. 命名是否規范？變量、函數、類、常量的命名是否清晰易懂，能否準確反映其含義（避免拼音、縮寫不明確的命名）？
2. 注釋是否完整且必要？
   • 復雜邏輯、算法是否有注釋說明設計思路？
   • 函數/類是否有文檔注釋（如參數含義、返回值、異常說明）？
   • 是否存在冗余注釋（如注釋與代碼完全重復）或過時注釋？
3. 代碼格式是否統一？縮進、換行、空格等是否符合團隊編碼規范（可通過格式化工具保障）？
4. 代碼結構是否清晰？是否避免了過度嵌套（如多層if-else、循環嵌套）？是否通過拆分函數/類降低復雜度？

三、安全性

1. 輸入驗證是否完善？是否存在注入風險（如SQL注入、XSS、命令注入）？
2. 敏感數據（如密碼、token）是否加密存儲/傳輸？是否避免在日志中明文打印敏感信息？
3. 權限控制是否嚴謹？是否校驗了用戶/角色的操作權限？
4. 依賴是否安全？是否使用了存在已知漏洞的第三方庫（可通過工具掃描確認）？
5. 異常處理是否合理？是否避免將詳細錯誤信息直接暴露給用戶（如堆棧信息）？

四、性能與效率

1. 是否存在明顯的性能瓶頸？
   • 數據庫查詢是否優化（如是否避免全表掃描、是否合理使用索引）？
   • 循環/遞歸是否存在不必要的重復計算？
   • 大數據量處理是否考慮分批、異步等方式？
2. 資源使用是否合理？
   • 是否及時釋放資源（如文件句柄、數據庫連接、內存）？
   • 是否存在內存泄漏風險（如未銷毀的定時器、全局變量無節制增長）？
3. 網絡請求是否優化？是否避免不必要的請求（如重復請求、冗余數據傳輸）？

五、可維護性

1. 代碼是否符合DRY原則（Don't Repeat Yourself）？是否存在重復代碼（可通過抽取公共函數/工具類優化）？
2. 耦合度是否過低？模塊/類之間是否存在過度依賴（如直接修改其他類的私有屬性）？
3. 擴展性是否良好？是否便于后續功能迭代（如通過配置、抽象接口替代硬編碼）？
4. 是否遵循團隊編碼規范/設計模式？是否與項目現有代碼風格保持一致？

六、錯誤處理與健壯性

1. 異常處理是否全面？是否捕獲了可能的異常（如網絡錯誤、數據格式錯誤）并進行合理處理（如重試、降級、友好提示）？
2. 是否存在空指針/未定義引用風險？對null/undefined的處理是否嚴謹？
3. 邊界條件是否考慮？如數組越界、數值溢出、字符串長度限制等。
4. 日志打印是否合理？是否包含關鍵操作日志（便于問題排查），且日志級別（info/warn/error）使用得當？

七、其他細節

1. 是否刪除了調試代碼（如console.log、斷點、測試用臨時變量）？
2. 配置是否合理？是否區分了開發/測試/生產環境的配置？
3. 代碼是否兼容目標運行環境（如瀏覽器版本、Node.js版本、操作系統）？

審查建議

• 結合自動化工具（如ESLint、SonarQube、PMD等）輔助檢查格式、潛在bug，聚焦人工審查邏輯和設計層面。
• 審查時以“幫助開發者提升”為目標，避免過度糾結細節（如命名風格爭議），優先關注功能和安全性問題。