跳到主要内容

从日志和 JSON 里把 UUID 提取出来:批量收集 ID 的本地做法

教你从一坨日志、JSON 或客服文本里把所有 8-4-4-4-12 格式的 UUID 抓出来,去重后导出,用来排查问题、收集订单 ID 或批量查询,全程在浏览器本地完成。

发布于 作者 李雷
#UUID #日志排查 #数据清洗 #开发工具

从日志和 JSON 里把 UUID 提取出来:批量收集 ID 的本地做法

排查线上问题的时候,我手里经常是一段几百行的日志,或者一份从接口抓下来的 JSON。要做的事很简单:把里面所有的 UUID 挑出来,拿去数据库批量查。可真动手就麻烦了,UUID 散落在日志行、JSON 键名、堆栈里,中间夹着时间戳、IP、路径,肉眼一个个抠又慢又容易漏。这篇说说我现在的做法。

UUID 长什么样,机器怎么认

标准 UUID 是 36 个字符,固定的 8-4-4-4-12 分段,中间用连字符隔开,每段都是十六进制字符(0 到 9、a 到 f)。匹配它的正则是这样:

[0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{4}-[0-9a-fA-F]{12}

也就是先 8 位十六进制,接一个连字符,再 4 位、4 位、4 位,最后 12 位。这条规则能精准命中 550e8400-e29b-41d4-a716-446655440000 这种值,同时把长度不对的哈希、订单号、随机串排除掉。提取器内部就是靠这条规则扫一遍全文,把所有命中行号一并记下来,不管 UUID 是带引号、带大括号还是裸在日志里。

一段真实日志,提取出一串 ID

举个我手边的例子。这是一段服务端日志片段:

2026-06-13 09:14:02 INFO  order created order_id=7d44e3b9-1c8a-4f02-9b5e-2a1f0c3d6e88 user=alice
2026-06-13 09:14:03 WARN  payment retry txn=7d44e3b9-1c8a-4f02-9b5e-2a1f0c3d6e88 attempt=2
2026-06-13 09:14:05 ERROR refund failed ref=c2f8a610-44bd-4e7a-bb19-9f0d12ab34cc code=PERMISSION_DENIED
2026-06-13 09:14:07 INFO  callback ok session=f0e1d2c3-b4a5-4968-8071-6a5b4c3d2e1f

把这四行粘进去,得到的去重列表是:

7d44e3b9-1c8a-4f02-9b5e-2a1f0c3d6e88
c2f8a610-44bd-4e7a-bb19-9f0d12ab34cc
f0e1d2c3-b4a5-4968-8071-6a5b4c3d2e1f

注意第一个 ID 在日志里出现了两次(下单和支付重试),去重后只留一条。原本四行带着时间戳、等级、键名的噪音,现在剩三个干净的 ID,直接复制到 SQL 的 WHERE id IN (...) 里就能批量查。这正是我用 UUID提取器 的高频场景。

排查问题、收集订单 ID、批量查询

提取出来的列表,我一般用在三类活上。

第一类是问题排查。客服把工单原文甩过来,里面散着会话 ID、订单 ID,我抓出来挨个查状态,定位是哪一笔卡住了。

第二类是收集订单 ID。运营导出一份 CSV 或者从后台复制一片表格,我要的只是那一列资源 ID,提取器会跳过其它字段,只留 UUID。

第三类是批量查询。把清洗后的列表导出成 SQL IN 片段或者 JSON 数组,丢给脚本跑一轮,省掉手工补引号、补逗号的麻烦,也不会漏掉某个逗号导致语法报错。

去重和保留无效项,各有各的用处

收集 ID 时最烦的就是重复。一个订单在日志里被打了五次,你查库时不需要查五遍。去重是默认就该做的一步,只保留唯一值。如果你只想做去重这一件事,也可以直接用 UUID去重工具

但有时候我会特意把无效项也带出来复核。所谓无效,通常是长度不对的十六进制串,或者碰巧长得像 UUID 的哈希值。把它标红出来,我就知道正则到底抓到了什么不该抓的东西,顺手验证一下数据源有没有脏数据。需要严格校验格式时,我会再过一遍 UUID校验工具

为什么坚持本地处理

这一点对我很重要。日志和工单里往往带着客户的真实标识、内部资源 ID,甚至访问 token。这类东西我不愿意贴到任何会上传的在线工具里。

UUID提取器的解析、校验、去重、导出全在浏览器这一个标签页里跑,上传的文本文件是通过 File API 在本地读取的,不会发到服务器。我可以放心地把生产日志整段粘进去。要提醒一句:UUID 格式正确不代表对应的账号或资源真的存在,校验只管格式,不管真实性。复制或下载带客户数据的结果时,该按数据权限处理还是要处理。

源文本一般是应用日志、SQL 结果或粘进来的载荷,几 MB 之内都没问题。真要是上 GB 的日志归档,先在本地 grep 出相关行再粘进来更稳。

把混乱的日志、工单、导出文件整理成一份可复核、可交接的 ID 列表,这件原本要手抠十分钟的事,现在几秒就完了。


Made by Toolora · Updated 2026-06-13