UUID 去重实战：大写、小写、带花括号都算同一个的去重复 ID 方法

做后端和运营的人多半遇到过这种尴尬：从三份导出里拼出一列 UUID，肉眼看着像是两千条不同记录，真去重之后只剩八百多条。中间那一千多条不是真的不同，只是有人用大写写、有人用小写写，还有人从 .NET 或 Windows 注册表里复制出来时带上了花括号。要数清真实的独立订单、独立会话、独立记录，先得让这些写法归到一起。

为什么大写、小写、带花括号是同一个 UUID

UUID 本质上是一个 128 位的数字，标准写法是 32 个十六进制字符按 8-4-4-4-12 分组，中间用连字符隔开。十六进制里 A 和 a 代表的值完全相同，所以 550E8400 和 550e8400 指向的是同一个数字。花括号只是某些平台（典型是 .NET 的 Guid.ToString("B")）习惯的包裹符号，去掉之后里面的值一字不差。

换句话说，下面三种写法在数据库里命中的是同一行：

550E8400-E29B-41D4-A716-446655440000
550e8400-e29b-41d4-a716-446655440000
{550e8400-e29b-41d4-a716-446655440000}

如果你的去重脚本只做了字符串完全相等比较，这三条会被当成三个不同的 ID，统计结果直接虚高。

归一化比较：转小写、去花括号再比对

正确的做法是先归一化，再比较。具体一点说，比对前对每个值做这几步：

去掉首尾空白和不可见字符
剥掉外层花括号 {} 或尖括号
把所有字母统一转成小写
用归一化后的结果作为去重的 key

这样 {550E8400-...} 经过 trim、去括号、转小写之后，归一化结果就是 550e8400-...，和裸写的小写版本得到完全一致的 key，于是被判为重复。UUID去重工具内部正是按这个 key 折叠的，输出时每个 key 只保留首次出现的那一行，并把命中次数记下来，所以你既得到干净清单，也保留了「这个值出现过几次」的证据。

一个真实输入输出例子

我前阵子合并两个客服系统的工单导出，会话 ID 全是 UUID，但两边大小写风格不一样，其中一份还是带花括号的旧格式。直接拼起来是这样一段输入：

550E8400-E29B-41D4-A716-446655440000
{550e8400-e29b-41d4-a716-446655440000}
550e8400-e29b-41d4-a716-446655440000
6BA7B810-9DAD-11D1-80B4-00C04FD430C8

把它粘进去、勾上去重，输出折叠成两行：

550e8400-e29b-41d4-a716-446655440000   出现 3 次   首次第 1 行
6ba7b810-9dad-11d1-80b4-00c04fd430c8   出现 1 次   首次第 4 行

四行输入，真实独立会话只有两个。前三行虽然写法各异，归一化后 key 相同，被合并成一条并标注出现 3 次；最后一行是另一个独立值。这一下就把「看着像四个会话其实只有两个」的真相摆出来了，统计独立订单、独立记录也是同一个逻辑。

统计独立数量，而不是行数

很多人统计「有多少个不同 UUID」时直接数行数，这在数据有重复和写法不一致时会严重偏高。去重之后的输出行数才是真实的独立数量。你可以只保留唯一值看总量，也可以把重复次数一起带出来，分析哪些 ID 被重复记录得最多，常常能顺藤摸瓜发现重复写入的 bug 或重复上报的埋点。需要核对来源时，把无效项也保留出来复核很有用，被截断或多打一位的 UUID 会清楚地暴露出来，而不是悄悄混进结果里。

本地处理，数据不离开浏览器

UUID 常常对应订单号、用户会话、内部资源标识，属于不该随便外传的数据。解析、归一化、去重、复制和下载全程在浏览器本地完成，上传的本地文件也只是用 File API 在当前标签页读取，不会发到服务器。几万行、几 MB 的查询结果或事件日志都是常态规模，本地跑足够快；真要处理上百 MB 的整表导出，先在本地切分再分批处理。

清洗完之后，输出可以在逐行、CSV、JSON、SQL IN 和 TypeScript union 之间切换，直接拿去喂脚本或写进数据库。如果你需要的不止去重，还想把单个值规范成标准 8-4-4-4-12 形式，可以接着用 /zh/t/uuid-normalizer/ 做格式归一；而完整的去重清洗流程，用 /zh/t/uuid-deduplicator/ 一步到位。

Made by Toolora · Updated 2026-06-13