Dev／UAT／Prod 是什麼？軟體開發環境完整解析｜2026 山葵組

Dev、UAT、Prod 是軟體開發中最常見的三個環境。Dev（Development）是開發環境，工程師撰寫與初步測試程式的地方；UAT（User Acceptance Testing）是使用者驗收測試環境，上線前讓客戶或業務人員確認功能是否符合需求；Prod（Production）是正式環境，也就是真實使用者實際使用、存放真實資料的系統。

把程式分成多個環境，目的是讓每一次修改都先在不影響真實使用者的地方驗證，確認沒有問題才進入正式環境。以下說明各環境的角色、常見的第四個環境 Staging、資料與設定如何區分，以及小型專案實際需要幾個環境。

Dev、UAT、Prod 是什麼？三個環境的差異

Dev 開發環境

工程師開發新功能、修正錯誤的地方，可能是個人電腦上的本機環境，也可能是團隊共用的開發伺服器。程式碼隨時在變動，穩定性最低，資料通常是假資料或少量測試資料。

UAT 使用者驗收測試環境

功能開發完成後部署到 UAT 環境，由客戶、產品負責人或實際使用者依照真實作業情境操作，確認功能與流程符合需求。UAT 的重點是「業務上是否正確」，例如報價的簽核順序、訂單金額的計算方式，而不只是程式有沒有錯誤。驗收通過後，才會安排上線。

Prod 正式環境

真實使用者使用的系統，處理的是真實的客戶資料、訂單與交易。任何錯誤都會直接影響營運，因此正式環境的變更需要最嚴格的控管，通常只接受已經在前面環境驗證過的版本。

Staging 和 UAT 有什麼不同

許多團隊還會設置 Staging（預備環境），容易與 UAT 混淆。兩者的差別在於目的：

UAT 偏向業務驗收：確認功能是否符合使用者需求，由業務端或客戶參與。
Staging 偏向技術驗證：與正式環境設定幾乎完全相同的複製品，用來確認部署流程、效能，以及與外部服務的串接在正式條件下是否正常，通常由技術團隊負責。

小型專案常把兩者合併成一個環境；系統規模較大、上線風險較高時，才會分開設置。另外也有團隊使用 SIT（System Integration Testing，系統整合測試）或 QA 環境，專門讓測試人員進行完整的功能與整合測試。名稱不同，核心概念一樣：越接近正式環境，設定越接近真實、變更的控管也越嚴格。

一個功能從開發到上線的流程

典型的流程是：工程師在 Dev 完成開發與基本測試；程式碼合併後部署到 UAT，由客戶或業務人員驗收；驗收通過後部署到 Staging 做上線前的最後確認（若有設置）；確認無誤後排定時間部署到 Prod，並在上線後觀察系統狀況。

這個流程的關鍵是「同一份程式碼依序往前推進」，而不是在各個環境各自修改。在 UAT 發現問題時，應該回到 Dev 修正後重新部署，而不是直接在 UAT 或正式環境上修改，否則各環境的程式會逐漸不一致，出問題時難以追查。

為什麼不能直接在正式環境修改

正式環境承載真實的使用者與資料，未經驗證的修改一旦出錯，可能造成服務中斷、訂單錯誤或資料毀損，而且影響是立即的。即使只是「改一行設定」，也可能因為與其他設定的連動而引發意料之外的問題。

另一個常被忽略的風險是可追溯性。直接在正式環境修改的內容不會留在版本控制紀錄中，下一次正常部署時很可能被覆蓋掉，同樣的問題又重新出現。

各環境的資料與設定該怎麼區分

資料要隔離

Dev 與 UAT 應使用測試資料或經過去識別化處理的資料，只有 Prod 使用真實資料。為了方便測試而把正式資料庫直接複製到測試環境，會讓客戶個資暴露在防護較弱的環境中，有違反個人資料保護法規的風險。

設定與金鑰要分開

資料庫連線、API 金鑰、第三方服務帳號都應依環境分開設定，通常透過環境變數管理。金流是最典型的例子：測試環境要串接金流商提供的測試環境，避免驗收時產生真實扣款；推播與 Email 服務也要區分，避免測試訊息寄給真實客戶。

測試環境不該被搜尋引擎收錄

UAT 或 Staging 若使用公開網址，應透過 robots.txt、noindex 標記或登入保護，避免測試頁面被 Google 收錄，造成與正式網站重複的內容，或讓外部使用者誤入尚未完成的系統。

小型專案也需要這麼多環境嗎

不一定需要四個環境，但至少要區分「開發」與「正式」。直接在正式環境上開發，是最常見也最危險的做法。

多數企業系統建議至少設置 Dev、UAT、Prod 三個環境：開發在 Dev、驗收在 UAT、使用在 Prod。是否另外設置 Staging，取決於上線風險與系統規模。系統若牽涉金流、訂單或大量使用者，一次錯誤部署的代價很高，多維護一個環境的成本通常值得。

部分專案會在 UAT 驗收期間就先開放正式環境給少量使用者試用，這種做法的利弊可參考開發測試期間同步開啟正式站的優缺點。

CI/CD 與多環境部署

環境一多，手動部署就容易出錯，例如把測試設定帶到正式環境，或漏掉某個檔案。CI/CD（持續整合與持續部署）把「測試、建置、部署到各環境」的流程自動化：程式碼合併後自動執行測試並部署到 UAT，驗收通過後再以一致的流程部署到正式環境。

自動化的價值不只是節省時間，而是讓每一次部署都走同樣的步驟、留下同樣的紀錄，降低人為疏失。開發流程與環境規劃，也是系統上線後能否穩定維運的關鍵，整體做法可參考客製化系統開發。

常見問題 FAQ

Q1. UAT 是什麼意思？
UAT 是 User Acceptance Testing（使用者驗收測試）的縮寫，指上線前由客戶或實際使用者在測試環境中操作，確認功能與流程符合需求的階段，也常用來指稱這個測試環境。

Q2. 開發環境、測試環境、正式環境差在哪？
開發環境（Dev）是工程師撰寫程式的地方，變動最頻繁；測試環境（UAT）用來驗收功能；正式環境（Prod）是真實使用者實際使用、存放真實資料的系統。

Q3. Staging 和 UAT 有什麼不同？
UAT 偏向業務驗收，確認功能符合需求；Staging 偏向技術驗證，是與正式環境設定幾乎相同的複製品，用來確認部署與效能。小型專案常合併，大型專案會分開設置。

Q4. 為什麼不能直接在正式環境修改？
正式環境承載真實使用者與資料，未經驗證的修改一旦出錯會直接造成服務中斷或資料毀損；而且修改不會留在版本控制中，下一次部署時可能被覆蓋。

Q5. 小公司也需要分這麼多環境嗎？
至少要區分開發與正式環境。多數企業系統建議設置 Dev、UAT、Prod 三個環境；是否另外設置 Staging，視上線風險與系統規模而定。

Q6. 各環境的資料一樣嗎？
不一樣。Dev 與 UAT 應使用測試資料或去識別化資料，只有 Prod 使用真實資料。把正式資料直接複製到測試環境，有個資外洩與違反法規的風險。

Q7. CI/CD 跟多環境有什麼關係？
CI/CD 將程式從測試、建置到部署至各環境的流程自動化，讓每次部署的步驟一致，減少人為錯誤並加快交付。