必须使用 Collection v2.1 格式导出，因其完整支持脚本、变量作用域、嵌套结构和细粒度认证配置；v2.0 会丢失 event.type 和变量作用域，v1 彻底删除脚本；导出时勾选“Include environment variables”仅硬编码变量值，不保留定义元信息。
Postman 导出集合时选错版本，大概率会导致导入失败、变量丢失、脚本不执行，甚至在 Newman 命令行运行时报 TypeError: Cannot read property 'length' of undefined 这类看似无关的错误——根本原因往往就卡在版本兼容性上。
Collection v2.1 是当前唯一推荐的导出格式
v2.1 格式自 Postman v8 起成为默认，它完整保留 event（如 test 和 prerequest 脚本）、variable 作用域标记、folder 嵌套结构、以及 auth 配置的细粒度类型（如 apikey 的 key/value/in 字段）。v2.0 虽仍可导入，但会丢弃 event.listen 中的 beforeScript 类型声明；而更老的 v1 格式已彻底移除对脚本的支持。
- 如果你用到了
pm.test或pm.sendRequest，必须选 v2.1 - 团队协作或 CI/CD 场景下，禁止使用 v2.0 —— 它无法表达环境变量的
_postman_variable_scope字段，导致导入后所有变量变成全局作用域 - v2.1 文件里
info.schema固定为"https://schema.getpostman.com/json/collection/v2.1.0/collection.json"，可用 VS Code 快速验证：Ctrl+F 搜这个字符串，有则大概率是合规 v2.1
别碰 Collection v2.0 和 v1，除非你明确知道后果
v2.0 在 Postman UI 里仍可见，但它本质是 v2.1 的“降级快照”：导出时自动抹掉 event 中的 type 字段、折叠 variable 的 type 和 enabled 属性。v1 更危险——它把整个 event 数组直接删掉，且不报错。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 收到别人发来的
.json文件？先打开看item下有没有event字段，再确认info.schema是不是以v2.1.0结尾 - 用 Newman 运行时报
ReferenceError: pm is not defined，90% 是因为导出用了 v2.0 或更低版本 - 导出时若误选 v2.0，即使立刻重导 v2.1，也得手动检查所有请求的 Tests 标签页是否还存在脚本内容——UI 不会提示脚本已被剥离
导出时勾选 “Include environment variables” 实际只导出值，不导出定义
这个选项容易被误解为“连同环境一起导出”，其实它只是把当前选中环境里已解析的变量值，硬编码进 collection 的 variable 字段里。比如环境里定义了 baseUrl = https://dev.api.com，勾选后导出的 v2.1 文件中会出现：
{
"variable": [{
"key": "baseUrl",
"value": "https://dev.api.com",
"type": "string"
}]
}
但不会包含该变量的原始定义位置、作用域、是否加密等元信息。
- 跨环境迁移（dev → staging）时，千万别依赖这个选项——它会让所有请求的 URL 写死，失去环境切换能力
- 真正需要共享环境配置，请单独导出
environment文件，而不是勾选这个 - 如果导出后发现 collection 文件体积异常大（比如 >5MB），大概率是误勾了此项，且环境里存了 token 或 base64 图片等大字段
v2.1 格式不是向后兼容的“保险绳”，而是当前生态的事实标准；任何绕过它的选择，都会在协作、自动化或调试环节露出破绽——尤其当别人用新版本 Postman 导入你导出的 v2.0 文件时，那个静默消失的 pm.environment.set() 调用，可能要花半小时才能定位到根源。
