測試環境應該用合成地址資料，而不是複製生產客戶資料

最快的測試資料往往最危險

當測試資料庫是空的，最快的方法就是從生產環境複製一部分資料。這樣立刻有真實姓名、地址、電話和訂單歷史，但也立刻多了一個可能洩露敏感客戶資料的地方。

真實地址一旦和個人、帳號或家庭關聯，就屬於敏感資訊。複製到 staging 後，它可能出現在日誌、截圖、分析工具、崩潰報告、工單和演示環境裡。

生產資料和合成資料對比

合成不等於粗糙

差的合成資料很容易看出來：123 Test Street、Test City、00000。它能填欄位，但不能測試產品。好的合成資料遵循郵政格式，讓城市和地區一致，並包含公寓地址、長欄位、免稅州、國際郵遞區號等真實變化。

目標不是假裝產生資料是真實客戶資料，而是在不暴露真實個人的前提下，讓測試環境足夠接近真實業務。

哪些場景更應該預設用合成地址資料

• 本地開發資料庫。
• Staging 和 QA 環境。
• Bug 重現步驟和截圖。
• 銷售演示和產品 walkthrough。
• 新工程師和測試人員培訓資料。
• 自動化測試 fixture 和 CI 任務。
• 公開文檔和 API 示例。

什麼時候仍然需要治理生產型資料

有些團隊需要生產分布：真實城市頻率、常見郵遞區號模式、歷史訂單量。這不等於必須暴露原始客戶記錄。可以根據聚合模式產生合成記錄，讓個人欄位和真實身份斷開。

如果測試確實需要生產資料，就應該當成受控例外：減少欄位、盡量脫敏、限制存取、設定保留期限，並記錄為什麼合成資料不夠。