如何为模型及其关联数据生成唯一ID以快速校验重复订单

该ID的核心作用是唯一映射「商品+对应数量」的组合，只要订单的商品数量组合完全一致，生成的ID就完全相同，和订单创建时间、所属用户、优惠信息等其他属性完全无关。

1. 确定参与哈希计算的最小特征集 #

• 仅纳入和重复判定规则强相关的字段：这里仅保留所有订单行的商品唯一标识、对应购买数量，Order、OrderLineInfo中的其他无关字段（如单价、优惠、行备注、配送信息等）全部排除，避免无关字段变更导致哈希值失效
• 所有订单行必须按统一规则排序：比如按商品ID固定升序排列，避免同一个商品组合因为订单行插入顺序不同，生成不同的哈希值

2. 哈希计算的统一规范 #

• 优先选择低碰撞率的哈希算法：生产环境推荐使用SHA-256，如果对存储长度敏感，非加密场景下SHA-1的碰撞概率也完全可以满足业务需求，不推荐使用MD5，碰撞风险远高于前两者
• 固定全局统一的序列化规则：比如统一用[商品ID1:数量1,商品ID2:数量2,...]的格式拼接字符串，所有分隔符、大小写规则要全局统一：比如商品ID为字符串时统一转小写，数量统一转为不带小数的整数字符串（如果业务支持小数数量，统一约定保留的小数位数），避免类型、格式差异导致拼接结果不同
• 如果OrderLineInfo中存在需要纳入判定规则的字段（比如同商品同数量但规格不同也算不同订单），提前将对应字段加入每行的拼接规则，例如调整为[商品ID1:数量1:规格值1,商品ID2:数量2:规格值2,...]

举个实际计算示例：某订单包含两个商品，商品ID 1001 购买2件，商品ID 1003 购买1件。首先把所有订单行按商品ID升序排序，按固定规则拼接为字符串 1001:2,1003:1，对该字符串计算SHA-256得到哈希值，就是最终要存储的内容ID。

3. 存储与查询优化 #

• 该字段可命名为order_content_hash，不要和订单业务主键、分布式ID混淆，根据业务需求建索引：如果不允许重复订单提交就建唯一索引，仅需要查询重复就建普通索引
• 数据量极大的场景可以额外存储该哈希的前8位作为content_hash_short字段，查询时先拿短哈希做前置过滤，匹配到后再校验完整哈希，可降低索引存储成本、提升查询速度
• 新建订单时先计算该哈希，直接查询对应索引即可判定是否存在重复订单，无需关联查询订单行表，性能比全量比对高2~3个数量级

4. 边界场景兼容 #

• 如果商品ID存在变更、映射规则调整，要同步维护哈希计算的兼容逻辑，避免老订单的哈希和新订单相同组合的计算结果不一致
• 数量支持小数的场景，要统一精度规则，比如统一保留2位小数，避免1和1.00被判定为不同值
• 提前约定空订单行场景的固定哈希值，避免异常计算结果导致漏判、误判

内容的提问来源于stack exchange，提问作者Ole Bille