替匯入資料補 UUID 時，應先保留原始副本、固定資料順序，再按照「實際資料列數」一次產生同批識別碼。UUID 不會辨認哪個值屬於哪筆訂單；如果貼錯欄或中途只排序一部分欄位，再好的識別碼也會和原資料錯配。
先做一張不會被排序打亂的對照
最先要確認的不是 UUID 格式，而是哪一列代表哪筆資料。先複製待匯入檔，替工作副本加上 source_row 或沿用現有訂單編號，並記下標題列、第一筆與最後一筆資料的位置。
例如測試環境要匯入 48 筆商品，欄位依序是 sku、name、price、item_uuid。建立 UUID 前，先確認 sku 沒有空白或重複，並把 item_uuid 放在固定的最後一欄。接下來若要排序，必須讓整個資料範圍一起移動，不能只選 item_uuid 或其中一個業務欄位。
原始副本的用途是回查，不是做完就刪除。若第 27 列開始錯位，可以比較工作副本與原始的 sku，找出第一次發生差異的位置；沒有這份對照時，只看到一串外觀正常的 UUID，往往無法判斷它原本應該屬於哪筆記錄。
依列數產生，並留下批次界線
UUID 產生器可在瀏覽器一次產生 1 到 100 組 UUID v4，也能選擇移除連字號或轉成大寫。先數清楚不含標題的資料列，再依目標系統規格決定格式，使用「複製全部」貼入第一個空白的 item_uuid 儲存格。
預設值會是像 d9428888-122b-4a96-9f20-3c4f52cdd3ac 的 36 字元形式。只有 API 或資料庫欄位明確要求 32 字元時，才使用去除 dash 的選項；大寫也只是輸出形式選擇，不能自行假設接收端會把不同形式視為相同值。
工具只會產生文字並複製結果，不會開啟 CSV、不會偵測標題，也不會把值寫回檔案。它同樣不知道第 12 個 UUID 應該對應哪個 sku，因此貼上前後都要由工作表中的列位置維持關係。
資料超過 100 筆時，可按 2–101、102–201 這類清楚範圍分批。每一批都記下起始列、結束列、資料筆數與首尾 sku，貼完立刻檢查，不要等全部批次完成後才找錯位。
用四個檢查攔住常見錯配
貼上 UUID 後，至少要檢查數量、空值、重複與列對照。這四項分別攔截少貼一列、標題被算進去、舊值混入，以及局部排序造成的錯配。
- 數量：UUID 非空白筆數必須等於待匯入資料筆數。
- 空值：檢查第一筆、中段批次交界與最後一筆，確認沒有漏列。
- 重複：由試算表或目標系統檢查整欄唯一性，不能只目測幾個值。
- 列對照：同時查看
source_row、sku與item_uuid，確認三者仍在同一列。
產生器每次會建立新值，但它不會讀取整份資料，也不會替資料庫建立唯一索引。若正式系統已有同一批業務資料，應先匯出既有識別碼並依可靠鍵值配回，不要為舊記錄再產生一套 UUID，否則更新可能被誤判成新增。
若某批貼錯，最安全的處理不是在幾個空格中補值，而是回到工作副本，重新確認那一批的完整範圍，再建立新的批次並清楚作廢錯誤版本。這樣才能避免不同檔案各留一套看似有效的識別碼。
先以少量樣本驗證匯入映射
正式匯入前，先拿三到五筆不含敏感資訊的代表資料跑測試。測試重點不是 UUID 看起來是否隨機，而是匯入畫面有沒有把 item_uuid 對到正確欄位，且相鄰的價格、名稱或日期沒有整欄位移。
測試完成後，從目標系統查回第一筆、中間一筆和最後一筆，逐一核對 sku 與 UUID。若接收端只回報「匯入成功」，仍不能代表欄位對照正確；格式合法但貼錯欄的資料，也可能順利通過基本驗證。
若交付格式是 JSON，可把已去識別化的樣本貼進 CSV / JSON 互轉查看標題是否成為預期的物件鍵，再用 JSON 格式化工具檢查語法與錯誤位置。這兩個工具都不理解你的業務規則，語法通過後仍要人工確認同一個物件內的 sku、價格與 UUID 是否來自同一列。
最後保留一份已核對的映射紀錄，內容至少包括來源版本、批次範圍、匯入時間與抽查結果。日後若要更新同一批記錄，應沿用既有 UUID，而不是再次批次產生。
常見問題
UUID 產生器會直接修改 CSV 嗎？
不會。工具只在網頁中產生 UUID 文字並提供複製功能，不會讀取、編輯或儲存 CSV；貼入哪個欄位仍由使用者在試算表或資料流程中完成。
48 筆資料要產生 48 還是 49 組？
如果第一列是標題，通常應按 48 筆實際資料產生。還要排除說明列、空白列與小計列，不能只看工作表最末端顯示的列號。
去除 dash 之後還是同一種 UUID 嗎？
工具會輸出相同識別內容的無連字號形式，但接收端是否接受要看欄位規格。先確認長度、大小寫與驗證規則，再用少量資料測試。
產生後可以再排序資料嗎？
可以排序完整資料範圍，但不要只排序 UUID 欄或部分業務欄。匯入前若沒有必要，維持已核對的順序通常更容易追查批次問題。
匯入顯示成功，還需要抽查嗎？
需要。成功訊息可能只表示格式被接受，不能證明 UUID 與商品、客戶或訂單仍在正確的同一列；應查回代表記錄逐筆核對。