真正能长期维护的Postman集合需结构设计前置：命名带业务上下文（如user-service-staging），按环境拆集合，文件夹按“资源+操作”组织，变量分层注入，脚本按层级收敛，执行Runner验证结构合理性。
新项目一上来就往 Postman 里狂建请求，最后集合变成“接口坟场”——名字乱、层级平、变量满天飞、换环境全得手动改。真正能长期维护的集合，靠的不是堆请求，而是结构设计前置。
Collection 命名和描述要带业务上下文
别用“API_V1”“测试集合_01”这种命名。集合名就是项目标识，别人一眼得知道它对应哪个系统、哪个阶段。比如 user-service-staging、payment-gateway-prod。描述栏不是可选项，必须写清：对接方、协议版本、主要用途（如“用于支付回调验签联调”）、负责人邮箱或飞书ID。
- 避免空描述或“暂无”——后期协作时没人敢动这个集合
- 如果项目有多个部署环境（dev/staging/prod），建议按环境拆成不同集合，而不是塞进同一个集合里靠环境变量切换——容易误操作
- 集合名中不要含空格或特殊符号，否则导出为 JSON 或集成 Newman 时可能出问题
文件夹层级按“资源+操作”组织，别按 HTTP 方法分
常见错误是建四个文件夹：GET、POST、PUT、DELETE。这会让一个业务流程（比如“创建订单→支付→查询状态”）被拆到四个地方，无法串联执行，也违背 RESTful 资源语义。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 正确方式是先按资源划分，比如
/orders、/users、/webhooks - 每个资源文件夹下再按操作建子文件夹：
create、list、get-by-id、cancel（不是DELETE） - 如果某接口属于跨资源流程（如“登录后获取用户信息”），单独建
auth-flow文件夹，别硬塞进/users
变量必须分层，且禁止在请求体里硬编码 URL 或 token
看到 https://api.example.com/v2/users 直接写死在请求 URL 栏？或者把 Bearer xxxxx 粘在 Authorization 头里？这是集合崩溃的第一步。所有动态值必须走变量注入。
- URL 中的 host/port/path 版本号 → 用
{{base_url}}+{{api_version}}，定义在集合变量里 - 认证凭据（token、client_id）→ 放集合变量，配合
Authorization设置为Inherit auth from parent，让所有子请求自动继承 - 临时数据（如刚创建的 user_id、order_no）→ 用
Tests脚本提取并设为pm.collectionVariables.set("created_user_id", ...)，供后续请求引用 - 绝对不要在 Pre-request Script 里重复写
pm.environment.set("token", ...)—— 如果 token 是集合级的，就在集合 Variables 页统一维护
预请求脚本和测试脚本要收敛，别每个请求都写一套
很多人在每个请求里都粘贴一遍时间戳生成、签名计算、JSON Schema 校验代码，结果改一处逻辑，得翻 30 个请求去同步。脚本应该随集合结构下沉，而非随请求漂浮。
- 集合级预请求脚本（Collection → Pre-request Scripts）放通用逻辑：如统一设置
X-Request-ID、刷新过期 token、加载本地证书 - 文件夹级脚本（Folder → Pre-request Scripts）放模块专属逻辑：如订单模块里自动拼接
trace_id，用户模块里自动注入tenant_code - 单请求测试脚本只写该接口特有断言：比如
pm.response.code === 201、pm.response.json().data.status === "paid" - 所有脚本里禁止出现硬编码路径或正则——用
pm.collectionVariables.get("expected_status")这类变量替代
最常被忽略的一点：集合结构定稿前，先跑一次 Collection Runner，选中整个集合执行，看失败是否集中在某一层级（比如全是 401 就说明 token 注入没生效；全是 404 就说明 {{base_url}} 拼错了）。结构好不好，不是看目录多漂亮，而是看批量执行时哪一层最先暴露问题。
