UUID 列表批量转换：把一堆 ID 整理成代码能用的格式

每次从数据库导出、客服工单或日志里拿到一列 UUID，真正费时间的不是查数据，而是把这些 ID 整理成代码或查询能直接吃进去的格式。要不要去连字符？要不要每个值加引号？逗号分隔还是换行？大小写要不要统一？这些琐事手工做一遍，几十个 ID 就够让人烦躁，几百个时还容易漏逗号、多空格，最后 SQL 报语法错误。

这篇说清楚怎么把一批散装 UUID 批量转成可用格式，重点是转成数据库查询里的 IN 列表，以及 JSON 数组、TypeScript union。全程在浏览器本地完成，文本不上传。

为什么手工整理 UUID 列表这么费劲

UUID 本身长得就劝退：550e8400-e29b-41d4-a716-446655440000，36 个字符带 4 个连字符。一列几百个这样的值，常见的烦恼有这么几类：

来源格式乱：有的带连字符有的不带，有的大写有的小写，有的前后还粘着引号或逗号。
有重复：几份导出拼在一起，同一个 ID 出现好几次。
目标格式各异：写 SQL 要带引号逗号分隔，写 TypeScript 要 union，写脚本可能只要逐行。

这三件事叠在一起，手工搞就是在数逗号、对引号。批量工具的价值就是把规范化、去重、格式化这三步一次做完。

转成 SQL IN 列表：带引号、逗号分隔一步到位

最高频的需求是把一列 ID 塞进 WHERE id IN (...)。SQL 里每个 UUID 都得是字符串字面量，也就是要单引号包起来、逗号分隔。手工写到第十个就开始怀疑自己有没有漏引号。

打开 UUID 列表转换器，把 ID 粘进去，输出格式选 SQL IN，它会直接给你这样一段：

IN (
  '550e8400-e29b-41d4-a716-446655440000',
  '6ba7b810-9dad-11d1-80b4-00c04fd430c8',
  '6ba7b811-9dad-11d1-80b4-00c04fd430c8'
)

每个值都已经加好单引号、行尾补好逗号、最后一行不带多余逗号。直接拼到 DELETE FROM events WHERE id 后面就能跑。同样的列表换成 JSON 数组,就是给前端接口或测试 fixture 准备数据;换成 TypeScript union,就是一个 'id1' | 'id2' | 'id3' 类型,方便给一组固定 ID 做类型约束。

一个真实的输入输出例子

我自己上周排查一个数据问题，从两份 CSV 导出里翻出一批可疑订单 ID，复制出来时长这样，大小写不一、还混了重复和一个带前导空格的：

550E8400-E29B-41D4-A716-446655440000
 6ba7b810-9dad-11d1-80b4-00c04fd430c8
6ba7b810-9dad-11d1-80b4-00c04fd430c8
6ba7b811-9dad-11d1-80b4-00c04fd430c8

粘进去，勾上去重、统一小写、排序，输出选带引号的逐行列表，拿到的是干净的三行（重复那条被合掉了）：

"550e8400-e29b-41d4-a716-446655440000"
"6ba7b810-9dad-11d1-80b4-00c04fd430c8"
"6ba7b811-9dad-11d1-80b4-00c04fd430c8"

从乱糟糟四行到可用三行，没碰一次键盘改格式。这一步省下来的不只是时间，更是避免了那种「肉眼检查了三遍还是漏了一个空格」的反复。

去重和保留无效项，让输出和输入对得上

把几份来源拼起来时，重复几乎是必然。去重选项会按规范化后的值合并，也就是说大小写、连字符差异统一之后再判重，不会因为一个大写一个小写就当成两个。

另一个容易忽略的是无效项。如果某行根本不是合法 UUID（少了一段、混进别的字符），你可以选择把它带在输出里并标注原因，而不是悄悄丢掉。这样输出列表能和输入一一对应，回头排查时知道哪一行出了问题，不会出现「导出 200 个进去只剩 198 个」却不知道少在哪的情况。

配套的清洗与导出工具

UUID 列表转换器专做提取规范化和格式化这一段。如果你的活更偏某一类，可以直接用更专一的工具：只想去掉重复值，用 UUID 去重器；如果整理完想把结果做成一张 Markdown 表格贴进文档或工单，CSV 转 Markdown 表格能接着用。几个工具的解析逻辑一致，在它们之间倒腾同一批 ID 不会变形。

整理 ID 列表这种事，单看一次省不了几分钟，但它一周会重复很多次。把规范化、去重、格式化交给工具做完，剩下的脑子可以留给真正要排查的数据问题。

Made by Toolora · Updated 2026-06-13