C++ API 函數命名衝突系統同名函數導致編譯失敗：重命名與命名空間隔離

在 DLL 專案中自訂函數 PrintScreen(HWND, WORD, WORD, WORD, LPSTR, BOOL)，與 Windows SDK winuser.h 中的 PrintScreen(HWND, WORD, WORD) 同名但參數不同，導致 VS2012+ 編譯報「重新定義」錯誤（VS6.0 較寬鬆不報錯）。

根本原因

• C++ 不支援函數重載跨越不同命名空間/全域範圍的同名函數，若兩個宣告在同一作用域可見，即構成重新定義錯誤，即使參數列不同。
• windows.h 通常會被專案預編譯標頭或通用標頭引入，導致系統版 PrintScreen 進入全域命名空間。

解決方案（按推薦順序）

1. 重新命名自訂函數（最徹底）：
   加上專案/模組前綴，如 MyLib_PrintScreen、Utils_PrintScreen，語義清晰且零衝突。
2. 放入專屬命名空間：
   

   namespace MyProject {
       WORD WINAPI PrintScreen(HWND, WORD, WORD, WORD, LPSTR, BOOL);
   }
   // 調用時
   MyProject::PrintScreen(...);
   

   需確保標頭檔宣告與實作檔定義均在同一命名空間。
3. 取消包含 windows.h 或延後包含：
   在自訂函數宣告之前包含 windows.h，並用 #undef PrintScreen 取消巨集/函數宣告（極不推薦，破壞系統標頭完整性）。
4. 靜態連結/匿名命名空間限制內部可見性：
   若函數僅供 DLL 內部使用，標頭檔宣告為 static 或放在 namespace { ... }，不導出符號，但 WINAPI 通常暗示導出，故不適用。

最佳實務

• 專案命名規範：所有對外導出 API 必須加上唯一前綴（如 MYPROJ_、MyLib_），內部函數用匿名命名空間或 static。
• 避免使用 Windows API 常見名稱：Create、Open、Close、Read、Write、Print、Draw、Get/Set 開頭的通用動詞。
• 升級編譯器時嚴格檢查符號衝突，VS2012+ 對 C++ 標準一致性要求更高，VS6.0 時代的代碼需重構。

「不與系統同名」是 C/C++ 程式庫開發的鐵律，前綴命名法成本最低、效果最好。