测试数据关联记录如何使用 UUID：逐条分配、复用与核对

先写清关系：哪些字段代表自己，哪些字段引用别人

在本教程约定的数据结构中，客户记录使用 id 标识自身；订单记录也有自己的 id，同时使用 customer_id 指向客户的 id。这两个订单字段承担不同职责。新建一条订单时，要为订单自身分配新标识，但它的 customer_id 应复用所属客户已经登记的标识。

先在工作表或文本草稿中写出业务归属，再开始生成 UUID。这里约定客户甲对应订单甲一和订单甲二，客户乙对应订单乙一。客户甲、订单甲一等名称只是人工核对用的测试标签，不能代替最终引用字段，也不应依靠数组里的先后顺序推断归属。

建议建立一份映射表，至少包含记录标签、记录类型、自身 UUID、预期所属客户四列。客户行的所属客户可以记为不适用；订单行先填所属客户标签，待主记录标识确定后再补引用。这样即使稍后调整记录顺序，也有一份独立的预期关系可供检查。

1. 建立客户甲、客户乙两条主记录的登记行，暂时留空 UUID。
2. 建立订单甲一、订单甲二、订单乙一三条关联记录的登记行。
3. 明确登记：订单甲一和订单甲二属于客户甲，订单乙一属于客户乙。
4. 约定本组示意数据的客户 id 与订单 id 均独立分配，customer_id 只从客户映射中复制。

关系示意，并非真实案例：客户甲 → 订单甲一、订单甲二；客户乙 → 订单乙一。此时先确认归属，不急于填写 UUID。

逐条生成主记录 UUID，每次复制后立即登记

打开 [UUID v4 生成器](https://adsrom.com/tools/uuid-generator/)，点击 Generate UUID，然后使用 Copy result 复制当前标识。该工具提供随机 UUID v4 生成；页面说明 UUID v4 是具有固定版本和变体的 128 位标识。这里将它用于区分测试记录。

先处理客户甲：生成一个值后，立即贴入映射表的客户甲行，并把同一个值填入客户甲记录的 id。确认这两个位置完全一致，再生成客户乙的值。不要连续生成多个值后才回头凭记忆分配，也不要在尚未登记时覆盖当前结果。

完成两条客户记录后，将映射表作为后续引用的依据。订单需要客户标识时，从对应客户行复制已经保存的值。再次点击生成按钮得到的是供另一个标识使用的新值，不是找回客户甲原标识的方法。

本流程由你逐条复制和整理测试数据。生成器的使用说明并不等于已经替你写入数据库或完成关联设置；在进入下一步前，仍需检查当前工作副本里的登记结果。

1. 为客户甲点击 Generate UUID，复制后同步填入映射表及客户甲的 id。
2. 核对客户甲两处内容一致，再为客户乙生成并登记另一个值。
3. 对照两条客户记录，确认没有因重复粘贴而使用同一个 id。
4. 保存这份映射，后续所有客户引用均从对应行取值。

标识示意，并非工具实测输出：客户甲 id 为 7c3f9a20-6b14-4e82-9d57-2a0c6f841b35；客户乙 id 为 b18d6e43-2f90-47ac-a631-8e5b09c724df。实际操作请使用你自己生成并登记的值。

为订单分配自身标识，再填入客户的既有标识

客户标识固定后，逐条处理订单。每条订单的 id 按上一节的方法另行生成并登记；customer_id 则按照预先写好的归属关系，从客户映射表复制。一次完成一条订单的两个字段，再处理下一条，能让检查对象保持清晰。

订单甲一和订单甲二属于同一个客户，因此两者的 customer_id 应相同，但两条订单自身的 id 应不同。不要把引用字段中的重复值一律判定为错误：在这份一位客户对应多条订单的示意结构中，复用客户标识正是预期行为。

下面的 JSON 是完整的虚构示意数据，包含两条客户记录与三条订单记录。所有 UUID 都是教学用示意值。若将其改为自己的测试样本，应先替换客户 id，再同步替换指向该客户的全部 customer_id；订单自身的 id 另行分配。

1. 为订单甲一生成自身 id，从客户甲映射行复制 customer_id。
2. 为订单甲二生成另一个自身 id，再次复用客户甲的 customer_id。
3. 为订单乙一生成自身 id，从客户乙映射行复制 customer_id。
4. 逐行读出“订单标签、订单 id、所属客户标签、customer_id”，与预期关系表对照。

完整虚构示意，非真实业务数据，非工具运行结果：
{
  "customers": [
    {"label": "客户甲", "id": "7c3f9a20-6b14-4e82-9d57-2a0c6f841b35"},
    {"label": "客户乙", "id": "b18d6e43-2f90-47ac-a631-8e5b09c724df"}
  ],
  "orders": [
    {"label": "订单甲一", "id": "2e70b9c1-a638-452d-8f04-6c91d3eab527", "customer_id": "7c3f9a20-6b14-4e82-9d57-2a0c6f841b35"},
    {"label": "订单甲二", "id": "93a6f042-d1b7-4c85-b290-e6748a3d1f06", "customer_id": "7c3f9a20-6b14-4e82-9d57-2a0c6f841b35"},
    {"label": "订单乙一", "id": "d5048e79-3c62-41fa-97b0-a2e6195c8d43", "customer_id": "b18d6e43-2f90-47ac-a631-8e5b09c724df"}
  ]
}

分开验收 JSON 语法与记录归属

如果用 JSON 保存测试数据，可将 JSON 对象本身粘贴到 [JSON 格式化与校验工具](https://adsrom.com/tools/json-formatter/)，选择 Format 检查语法并整理缩进。复制上节示例时，只取从左花括号到右花括号的内容，不把前面的示意说明一并放入输入框。

标准 JSON 的键名和字符串需要双引号，不允许尾随逗号或注释。出现语法错误时，先按照报错检查引号、逗号和括号，再重新校验。格式化改变的是空白排版，不应指望它为你改正 customer_id 中填错的值。

语法通过后，进行第一轮关系核对：从每条订单出发，完整比较 customer_id 与客户列表中的 id，确认恰好找到一条对应客户记录，再核对该客户是否就是预期归属。只确认引用值存在还不够；订单甲一如果误填客户乙的标识，仍然能找到客户，却违反了测试设计。

第二轮从客户反向检查订单：客户甲应对应订单甲一和订单甲二，客户乙应对应订单乙一。这里的数量只服务于本示意场景，不能泛化为所有数据的规则。双向检查时同时读标签与完整标识，不只看字符串开头或结尾。

1. 先完成 JSON 语法检查，确认可以获得格式化结果。
2. 检查每条客户和订单记录的自身 id 是否已填入，是否存在意外重复。
3. 逐条确认 customer_id 能在客户 id 中找到唯一匹配。
4. 把匹配到的客户标签与最初登记的预期归属比较。
5. 从每个客户反向列出关联订单，确认没有漏单或多出不应归属的订单。

遇到错绑、空引用和重复值时，按字段职责修正

找不到客户时，先比较订单 customer_id 与映射表中的完整值，检查是否漏贴、夹带空格、缺少字符，或者复制了错误内容。若客户记录已经存在且标识正确，就从该客户映射行重新复制引用，不要为客户再生成一个新 id 来迎合错误引用。

能够找到客户但归属不对时，检查预期关系表。例如订单甲二误用了客户乙的标识，应将这条订单的 customer_id 改为客户甲已登记的值，并重做双向核对。无须因为一处错绑就重新分配全部记录的标识。

发现两条独立主记录用了同一个 id 时，先确定各条关联记录原本属于谁，再为需要更正的主记录分配新值，并更新明确属于它的引用。此时不要简单执行全局替换：旧值同时出现在两条主记录中，单看旧值无法区分原本归属。

如果 UUID 已复制却忘记对应哪条记录，先查映射表和当前数据中的已保存内容。无法确定的值应暂时标为未分配，不要凭外观猜归属。若必须替换某条记录的 id，要同步检查所有引用该记录的位置，再保存修订后的映射。

1. 把问题记录的标签、当前 id、当前引用和预期客户写在一起。
2. 先判断错误位于自身标识、引用内容还是预期关系登记。
3. 按已确认的归属修正工作副本，保留不需要变更的标识。
4. 重新执行正向匹配与反向订单清点，完成后更新映射表。

错误示意，非真实案例：订单甲二的 customer_id 被填为 b18d6e43-2f90-47ac-a631-8e5b09c724df。这个值能匹配客户乙，因此“引用存在”检查会通过；对照预期归属后，应改为客户甲的 7c3f9a20-6b14-4e82-9d57-2a0c6f841b35。

交付前常见疑问：何时复用，何时重新生成

同一份测试数据再次使用时，需要重新生成全部 UUID 吗？如果仍表示同一组测试记录，建议保留已确认的映射，便于比较测试结果。如果准备建立一组独立的新记录，再按新任务逐条分配标识，并同步重建引用。不要只更换主记录 id 而保留旧的 customer_id。

随机生成后还要检查重复吗？本流程仍要求检查当前数据中的重复分配，尤其是复制粘贴造成的两条记录共用一个值。不要把使用 UUID v4 理解为可以省略核对，也不要承诺标识绝对不会碰撞。

能把客户 UUID 当成访问凭证吗？不能依靠 UUID 本身完成身份认证。工具页面明确区分了唯一性用途与认证用途，并建议认证场景使用专门的安全令牌及适当访问控制。本文中的 customer_id 只表达关联关系。

怎样判断这次整理已经完成？应同时满足：所有记录有已登记的自身标识；每条订单引用唯一对应的客户；对应客户与预期归属一致；反向清点没有遗漏；若采用 JSON，语法检查已通过。交付时一并保留预期关系和标识映射，接手者才能复核归属，而不只是看到一组长字符串。

1. 保存最终测试数据以及对应的关系说明和 UUID 映射。
2. 明确注明数据为虚构测试用途，区分预期正确数据与刻意构造的错误测试数据。
3. 记录尚未解决的异常；未通过关联核对的工作副本不要标为已验收。