优先使用{{$uuid}}，因其为Postman 8.0+引入的标准RFC 4122 v4 UUID变量，语义明确；{{$guid}}为旧版遗留写法，虽实际也生成v4 UUID，但命名易引发格式误解，官方已推荐弃用。
Postman里直接用{{$uuid}}还是{{$guid}}？
两者都行，但语义和生成格式不同：{{$uuid}} 是 Postman 8.0+ 引入的明确命名变量，生成标准 RFC 4122 v4 UUID（如 550e8400-e29b-41d4-a716-446655440000）；{{$guid}} 是旧版遗留写法，实际也生成 v4 UUID，但名字容易让人误以为是 Windows GUID 格式（其实一样）。官方文档已推荐优先用 {{$uuid}}。
常见错误：在老版本 Postman（{{$uuid}} 会原样发送、不替换——此时必须降级为 {{$guid}} 或升级客户端。
- 新版（v8.3+）建议统一用
{{$uuid}}，语义清晰、兼容性好 - 若团队混用版本，保守起见可全用
{{$guid}}，行为一致 - 别混用：比如 URL 里写
{{$uuid}}，脚本里又用pm.environment.set("id", pm.variables.replaceIn("{{$guid}}"))——这不会自动同步，纯属多此一举
需要把 UUID 存成环境变量再复用？用 pm.environment.set() 而不是硬编码
如果你的流程是「先生成 UUID → 塞进请求头/Body → 后续请求还要用同一个值」，就不能只靠 {{$uuid}} 动态生成。因为每次发送都会刷新，前后两次请求拿到的是两个不同 UUID。
正确做法是在 Pre-request Script 里生成一次，存进环境变量，后续通过 {{uuid}} 引用：
const uuid = pm.variables.replaceIn("{{$uuid}}");
pm.environment.set("request_id", uuid);
然后在请求 URL 或 Header 中写 {{request_id}}。这样整个请求生命周期内用的都是同一个值。
Postman Mac版是一款专为macOS设计的API开发与测试工具，凭借简洁的界面和强大的功能，深受开发者喜爱。它支持发送各种HTTP请求（GET、POST、PUT等），轻松管理接口集合、环境变量和模拟服务器。Mac用户可享受原生性能、快捷键优化及与系统无缝集成的体验，适用于接口调试、自动化测试和文档生成。无论是个人项目还是团队协作，Postman for Mac都能提升API开发效率，是ma
- 别在 Tests 里存——那是响应返回后才执行，当前请求已经发出去了
- 如果多个请求需共享同一 UUID（比如创建资源 + 上传文件），确保它们共用同一套环境（Environment），否则变量隔离
- 注意变量名别冲突：比如你存了
pm.environment.set("uuid", ...)，就别再用{{uuid}}引用内置{{$uuid}}，否则会覆盖或混淆
Postgres 侧接收 UUID 字段时，要注意字符串长度和连字符
Postman 生成的 {{$uuid}} 默认带连字符（xxxx-xxxx-xxxx-xxxx-xxxx），而 PostgreSQL 的 UUID 类型能直接接受这种格式，但如果你用的是 TEXT 或 CHAR(36) 字段，也没问题；可一旦用了 CHAR(32) 或去掉了连字符的存储逻辑，就会报错或截断。
典型报错：ERROR: invalid input syntax for type uuid: "a1b2c3d4e5f67890"（缺连字符）或 ERROR: value too long for type character(32)（带连字符却只留 32 位）。
- Postgres 建表时，优先声明字段为
UUID类型，它原生支持标准格式，无需额外处理 - 如果必须用字符串类型，字段长度至少设为
CHAR(36) - Postman 侧不需要手动删连字符——除非后端 API 明确要求无分隔符，此时得用脚本：
pm.environment.set("uuid_clean", uuid.replace(/-/g, ""))
为什么用脚本生成 UUID 比内置变量更灵活？
内置 {{$uuid}} 简单够用，但遇到这些场景就得上脚本：
- 需要带前缀或后缀（如
req_{{$uuid}}）→ 内置变量不支持拼接，得用pm.variables.replaceIn("{{$uuid}}")拿到原始值再加工 - 要控制生成时机（比如仅在某条件成立时才生成）→ 内置变量每次必触发，无法加 if 判断
- 需验证 UUID 格式是否合法再使用 → 脚本能加正则校验：
/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}-[89ab][0-9a-f]{3}-[0-9a-f]{12}$/i.test(uuid)
真正容易被忽略的一点：Postman 的变量替换发生在请求构建阶段，而脚本里的 pm.variables.replaceIn("{{$uuid}}") 是同步执行的，但如果你在脚本里嵌套调用多次（比如循环生成一堆），要注意 JS 执行顺序和异步陷阱——不过 UUID 生成本身是同步的，这点倒不用太担心。
