假資料產生器
在你的瀏覽器中產生，不會傳送到任何地方。姓名為虛構，電話號碼使用保留的 555-01xx 範圍，IP 位址取自 RFC 5737 的文件用區段，不屬於任何真實的人或主機。
您輸入的內容不會被儲存、記錄或分享。
自訂你需要的欄位，一次產生最多 1,000 筆擬真的假資料，輸出為 JSON、CSV 或 SQL 的 INSERT 語句。所有處理都在瀏覽器中完成，不會上傳，也不會使用任何真實的個人資料。
使用方式
- 為每個欄位命名，並選擇它要放哪一種值。
- 選擇筆數，以及要 JSON、CSV 還是 SQL。
- 按下「產生」，然後複製結果。
為什麼保留範圍很重要
每個產生的值都取自正式保留給虛構用途的範圍。這不是吹毛求疵，而是「可以安心執行的測試」與「不能安心執行的測試」之間的差別。
電話號碼使用 +1-555-01xx，這是北美編號計畫（NANP）保留給虛構用途的一百個號碼區段；555 的其他號碼多年前已經開放實際指配，所以隨便用任何 555 號碼的老習慣已經不再安全。電子郵件地址與網址使用 example.com、example.org 和 example.net，這些由 RFC 2606 保留，保證永遠不會被任何人註冊。IP 位址則取自不會被路由的 RFC 5737 文件用區塊。
它所避免的事故有大量紀錄，而且一再發生：用滿是逼真地址的測試資料跑測試，結果寄了真正的郵件給真實的人；壓力測試撥打了真實的電話號碼；填好種子資料的測試環境資料庫被接到正式的 SMTP 轉寄伺服器。無法聯絡到任何人的測試資料，是從結構上解決這個問題，而不是靠作業流程。
真正能找出錯誤的測試資料
每筆都中規中矩的資料用起來很舒服，但沒什麼用。名字都是六到十個字母、字串都是 ASCII、選填欄位全部填滿：以此建立的測試會通過，卻完全無法告訴你正式環境會發生什麼事。
有了基本資料集之後，值得手動加入的情況包括：每個可為 null 的欄位都放入空字串與 null，因為兩者會走不同的處理路徑。含有撇號、連字號與非拉丁文字（包括中文）的名字，編碼錯誤與草率的跳脫處理就是在這裡浮現。長度剛好等於欄位上限的值，以及多一個字元的值。邊界日期，例如月底、年底、2 月 29 日、日光節約時間切換的那一天。你以為唯一的欄位出現重複值。一堆小紀錄中夾著一筆非常大的紀錄。
產生的資料能快速提供數量與結構，這正是測試分頁、排序、索引行為與畫面呈現所需要的。而驗證正確性需要的是那些難搞的資料列，通常值得刻意撰寫，而不是指望產生器剛好產生出來。
三種輸出格式
目的地是程式碼時就選 JSON：API 測試資料、模擬伺服器、種子腳本，或測試啟動時讀取的檔案。紀錄會輸出為物件陣列，鍵名就是你設定的欄位名稱。
CSV 適合大量匯入的管道，例如試算表、資料庫的 COPY、後台上傳表單；在匯入之前想先以表格檢視資料時，也適合選它。接收端要注意 CSV 常見的問題：會自動猜測型別的程式，會自行判斷任何看起來像數字的內容。
SQL 會針對你指定的資料表名稱輸出一般的 INSERT 陳述式，每列一句，不需要驅動程式或腳本，在任何用戶端都能執行。字串值以重複引號跳脫，數字直接寫出，布林值寫成 TRUE 與 FALSE，不是單純單字的識別碼會加上雙引號。大量種子資料建議把輸出包在交易中，因為在大多數資料庫引擎上，一千條各自獨立的陳述式執行起來很慢。
不要改用去識別化的正式資料
需要逼真的測試資料時，最誘人的捷徑是複製一份正式資料庫，再把個人資料欄位清掉。值得了解為什麼這種做法總是出問題。
刪掉姓名與電子郵件並不能讓資料集去識別化。郵遞區號、出生日期、性別這類普通屬性的組合，或是幾個時間戳記與地點的組合，往往只對應到一個人；關於重新識別所謂匿名資料集的研究相當多，結論也一致。與此同時，清理過的副本仍是一份完整精度的正式資料，卻放在存取控管較弱、開發人員權限較廣、備份無人追蹤的環境裡。
從結構描述產生資料，就能避開整類問題。資料結構正確卻沒有來源，所以就算從測試環境外洩，也只是一場沒有實際損失的事件。如果真的需要接近正式環境的分布，站得住腳的做法是對統計特性建模，再從模型產生資料，而不是轉換真實紀錄。
設計資料集，而不是填滿欄位
真實的測試資料不是隨機資料，而是形狀和正式環境一致的資料。真實的資料表是偏斜的：大部分客戶只有一筆訂單，少數幾個有好幾千筆；大部分文件很短，只有一份極大；大部分工作階段只持續一分鐘，少數持續一整天。若測試資料裡每個客戶都剛好有三筆訂單，那個會在擁有四千筆訂單的客戶身上卡住的查詢，就永遠不會浮現。
資料量重要的理由也一樣。分頁、排序和索引行為在五十列時看不出來，在五萬列時一目了然；一份短清單能瞬間渲染完成的頁面，換成真實資料量可能要好幾秒。產生比你預期多一個數量級的資料，是最便宜的負載測試。
第三項是參照完整性。訂單需要存在的客戶，留言需要對應的貼文，子紀錄需要日期合理的父紀錄——一筆在客戶註冊之前就下的訂單，會讓之後所有以它為基礎的報表都陷入混亂。
種子、決定性與可重現
每次執行都重新產生隨機資料的測試會時好時壞，而偶發性的失敗比穩定的失敗更糟，因為沒有人重現得出來。常見的紀律是固定種子：每次執行都是同一串序列，於是失敗可以重現，bisect 也才有意義。
這和想要多樣化資料的需求互相牴觸，多數團隊採取的折衷做法是使用帶種子的產生器，並把種子印在測試輸出裡。需要時就能重現，長期下來又保有變化；當某個罕見的組合弄壞了什麼，日誌裡的那個種子就能原封不動地重建它。
種子腳本也應該具備冪等性。跑兩次種子應該讓資料庫停在同樣的狀態，而不是每張表都翻倍；實務上這代表先清空資料表，或依自然鍵做 upsert。一個必須把資料庫砍掉才能重新灌種子的開發者，就會乾脆不重灌，而過期的本機資料本身就是一類錯誤的來源。
固定資料、工廠與快照
主要有三種模式，各自解決不同的問題。固定資料 (fixtures) 是測試前載入的靜態檔案：可預測、好閱讀，但不好維護，因為結構一改就得逐一修改每個檔案。工廠 (factories) 則在程式碼裡建立物件，帶有合理的預設值並可依測試覆寫，所以一項測試只需要寫出它真正在意的欄位——這是現代測試套件中最廣泛採用的做法。
快照則記下某個函式的輸出，並斷言它沒有改變。用在渲染和序列化上非常好用，但在沒有人真的去看差異時就很危險：一份把錯誤固化下來的更新後快照，是大型測試套件裡常見的失敗方式。
這個工具產生的那種資料，位在這三者的底層。它負責填滿量的部分——讓效能與分頁變得真實的那好幾千列——而個別棘手的紀錄則由人手寫出來，因為上個月弄垮正式環境的那個案例，值得明確地寫下來，而不是指望產生器碰巧重現它。
為什麼複製正式環境資料總是出問題
抓一份正式環境的傾印再把姓名抹掉，感覺是通往真實資料最快的一條路，但它失敗的原因是結構性的，而不是流程上的。移除直接識別資訊並不等於讓資料集去識別化：郵遞區號、出生日期和性別這類普通屬性的組合，往往只對應到一個人，而關於重新識別所謂匿名資料集的研究既大量又結論一致。
營運面的問題是另一回事，而且同樣嚴重。那份洗過的複本，是一份完整保真的正式環境資料集，卻住在存取控制較弱、開發人員接觸面更廣、備份沒人在追蹤的環境裡。在 GDPR 之下，假名化的資料仍然是個人資料，仍在規範範圍內；這是一般性的觀察而非法律意見，細節取決於你所在的司法管轄區和你的資料保護長。
從資料結構產生資料，可以整個繞開這一類問題。資料有正確的形狀，卻完全沒有來歷，所以從 staging 外洩就是一場沒有實質內容的事故。如果真的需要接近正式環境的分佈，站得住腳的做法是為統計特性建立模型、再從模型產生資料，而不是去轉換真實紀錄。
把輸出送到它該去的地方
對資料庫來說，SQL 輸出不需要驅動程式就能在任何用戶端執行，而把它包在一筆交易裡會讓大量灌種快上許多——在交易之外執行一千道個別語句，在幾乎每一種引擎上都很慢。專就 PostgreSQL 而言，一旦列數超過幾千，從 CSV 執行 COPY 會大幅勝過 INSERT 語句。
對應用程式來說，JSON 通常是正確的目標：測試在啟動時載入的固定資料檔、模擬伺服器的回應，或是 ORM 讀取的種子腳本。欄位名稱會完全照你設定的樣子輸出，所以讓它們對上模型的屬性名稱，就能省下一道對應的手續。
CSV 則適合有人參與的路徑——匯入前用試算表親眼看過、後台的上傳表單、大量匯入工具。只要記得另一端那些老生常談的 CSV 注意事項：會自行猜測型別的消費端，會對任何看起來像數字的東西自作主張，而參照編號開頭的零通常就是頭號受害者。
常見問題
- 產生的資料可以安全地提交到版本庫嗎？
- 可以，這是刻意設計的。姓名取自虛構名單，電話號碼使用北美號碼計畫保留給虛構用途的 +1-555-01xx 範圍，電子郵件與網址使用 RFC 2606 保留的 example.com 系列，IP 位址則來自 RFC 5737 的文件用區段。這裡產生的任何內容都不會連到真實主機或撥給真實的人。
- 為什麼不直接請 AI 助理產生測試資料？
- 如果只要三筆，那就用 AI。但若需要 500 筆且欄位固定，你要的是可重複性與精確的欄位名稱，那正是產生器的強項，而不是聊天視窗的。改一個欄位型別再重新產生，也比重寫提示更快，而且輸出永遠不會離開你的電腦。
- 假資料、測試資料、模擬資料有什麼差別？
- 實務上沒有差別，三個說法指的是同一件事，本頁都適用。真正重要的是形式：具名且有型別的結構化紀錄，而不是像 Lorem ipsum 那樣只能填版面、無法載入資料庫或 API 的佔位文字。
- SQL 輸出要怎麼使用？
- 輸出是針對你輸入的資料表名稱所產生的純 INSERT 語句，一筆一句，可直接在任何 SQL 用戶端執行。字串會以雙寫單引號的方式跳脫，數字不加引號，布林值寫成 TRUE 與 FALSE。不是單純識別字的欄位或資料表名稱會加上雙引號。
- 為什麼上限是 1,000 筆？
- 1,000 筆 JSON 已經是大約 100KB 的文字，正好是文字框開始變慢的臨界點。如果需要更多，請分批產生；ID 欄每次都會從 1 重新開始，若要載入同一張表就得自行調整。
- 隨機性夠好嗎？
- 來自 crypto.getRandomValues 並搭配拒絕取樣，與本站密碼產生器和 UUID 產生器使用的是同一個無偏隨機來源。虛構的城市名並不需要這種等級的隨機性，但把隨機實作維持成一份，需要做對的地方也就只有一處。
最後更新:
請提供操作步驟、預期結果及實際結果。請移除機密與個人資料。