iLoveDevTool測試資料的三種來路
給測試環境造資料，無非三條路：真實資料脫敏（合規成本高、脫敏不淨就是事故）、程式設計庫造數（faker.js 等，靈活但要寫程式碼）、線上產生器（貼上即得）。低頻與一次性任務——本地開發庫灌點資料、演示環境要些像樣的使用者、介面 mock 要份回傳——第三條路成本最低。
這篇講清楚線上造數時的欄位規則與格式實踐，讓生成的資料「形態真實、內容無害、格式正確」。
欄位型別：形態真實就夠了
假資料的第一原則是形態真實、內容無害——每個欄位型別要保真的是它的「形狀」：
- 姓名：中文測試裡 Zhang San 滿天飛是英文 faker 的老問題——中文系統該用中文姓名（姓+名組合，二到四字的自然長度）
- 信箱：
user@example.com是 RFC 2606 的保留域寫法，適合文件範例；造數場景更常用真實網域的隨機組合（形態像真信箱），但要記住它可能恰好撞上真實信箱——只作佔位，別發信 - 手機號：保真的是 1[3-9] 開頭 11 位的形態；隨機組合可能命中在用號碼，同樣只作佔位
- 城市/公司：常用池抽取——形態自然即可，不需要真實行政區劃
- 數字：區間很重要——訂單金額 0-1000 和點數 0-10^7 是兩個世界，min/max 是欄位定義的一部分
- 日期：見下文的坑
安全邊界：做與不做的區分
不是所有「能生成」的欄位都該做。判斷標準是生成物能否通過真實的校驗流程：
| 欄位 | 有無校驗場景 | 結論 |
|---|---|---|
| 姓名/城市/公司 | 無 | 做 |
| 信箱/手機號 | 形態校驗（非實名） | 做（佔位用途可控） |
| 身分證/銀行卡/護照 | 有校驗位演算法，可通過實名初篩 | 不做 |
證件號按演算法生成的假號是「合法形態」——能過前端校驗、能過部分實名介面初篩，挪用風險實質存在。這是負責任的假資料工具的邊界線。
日期生成的經典坑
「2020-2025 隨機日期」最容易寫錯的方式是年、月、日三個數獨立隨機——2023-02-30 就這麼來的。正確姿勢是 day-of-year 演算法：在範圍的天數跨度裡隨機一個偏移，從範圍起點加上偏移再格式化。閏年、大小月全部自動正確。
邊界也要寫死：「2020 到 2025」含不含兩端，測試斷言裡差一天就是失敗。
三種輸出格式的實踐
JSON：夾具與 mock 介面
陣列物件是最通用的形態，單元測試夾具、mock server 的回傳體直接可用。中文值不需要轉義成 \\uXXXX——現代工具鏈都按 UTF-8 處理，原樣可讀性更好。
CSV：表格與導數工具
RFC 4180 是底線：值裡含逗號、引號、換行時要引號包裹且內部引號雙寫。數字與布林不加引號——加了引號，下游的型別推斷（比如 CSV 轉 JSON 工具的動態型別）會把它們全當字串。
SQL：直接灌庫
完整的 SQL 輸出包含 CREATE TABLE（欄位型別從欄位型別推導：整數 INT、日期 DATE、其餘 VARCHAR）和分批的 INSERT。兩個易漏點：欄位名要做清洗（使用者輸入 order/user 這類保留字會讓建表語句直接報錯）和值內單引號的 '' 轉義。生成後想看排版更清楚的語句，接一手 SQL 格式化即可。
把 schema 變成資料
假資料產生器把上述規則做全：11 種欄位型別逐行定義（數值配區間），預置使用者表 schema 一鍵載入，1-1000 行即時生成，JSON/CSV/SQL 三格式輸出（SQL 含建表與轉義），中英資料集切換——中文系統的姓名城市不再是英文 faker 的違和輸出，全程瀏覽器本地。生成的 JSON 要檢查結構時接 JSON 線上解析，SQL 要排版用 SQL 格式化工具——造數到用數的工作流一站串起來。
常見問題
測試假資料常用哪些欄位型別？
主流的 11 種：姓名、使用者名稱、信箱、手機號、城市、公司、整數、小數、日期、UUID、布林。覆蓋了使用者表/訂單表等業務表的常見欄位——更複雜的欄位（地址全文、經緯度、巢狀結構）可以由這些基礎型別組合或後處理得到。
為什麼身分證號不該用工具生成？
身分證號帶校驗位演算法：按 GB 11643 規則生成的假號能通過多數前端的格式校驗，甚至部分實名介面的初篩——這類「合法形態」的假證件號存在被挪用於註冊和詐騙的實質風險，負責任的工具不應提供。手機號沒有校驗位場景、僅形態真實，佔位用途風險可控，這是做與不做的邊界。
假資料輸出 JSON、CSV 還是 SQL 好？
看用途：JSON 直接作單元測試夾具或 mock 介面回傳；CSV 貼表格、導資料工具；SQL（建表+插入語句）適合往資料庫裡灌數——本地開發庫跑一遍 INSERT 就有了一千行資料。三者的轉義規則不同（CSV 要處理逗號引號、SQL 要處理單引號與保留字欄位名），選對格式比自己手工轉義省事。
隨機日期生成有什麼坑？
最大的坑是「年月日獨立隨機」會產出 2 月 30 日這類非法日期——正確做法是先在範圍內隨機一個天數偏移再格式化（day-of-year 演算法），閏年自動正確。其次是邊界含混：說「2020 到 2025」要寫清是否含兩端，寫進測試斷言時差一天就是失敗。