登录接口必须独立建Collection，如auth-login-flow，仅含登录、刷新、登出请求；Pre-request脚本需清空旧token，Tests只校验状态码与code字段，避免干扰调试与自动化流程。
登录接口必须单独建一个请求，不能塞进其他集合里
登录接口不是普通接口，它是整个认证流程的起点，所有后续请求都依赖它返回的 accessToken 或 token。如果把它混在某个业务集合（比如 user-service-api）里，会导致两个问题：一是环境变量污染——别人运行你那个集合时，会意外覆盖自己的 accessToken；二是调试断裂——想重刷 token 却要先翻半天目录找登录请求。
实操建议：
- 新建一个独立 Collection，命名为
auth-login-flow或类似带明确语义的名字，不加业务前缀 - 这个 Collection 里只放 1～3 个请求：登录、刷新 token（如有）、登出（可选）
- 登录请求的 Pre-request Script 中必须清空旧 token：
pm.environment.unset("accessToken") - 不要给登录请求设置自动携带 token 的脚本——它自己就是发 token 的源头
Collection 层级怎么组织才不乱
Postman 的 Collection 支持嵌套文件夹（Folders），但很多人误以为“分得越细越好”，结果建出 user/management/login/v1/with-captcha 这种五层路径，反而增加维护成本。真实项目里，清晰比深度更重要。
推荐结构（以微服务为例）：
-
auth-login-flow（顶层 Collection，含登录+token刷新） -
user-service-api（顶层 Collection，含用户增删改查等） -
order-service-api（顶层 Collection，含订单创建、查询等） - 每个 Collection 内部用 Folder 按角色或场景分组，例如：
user-service-api下建admin-only、guest-access、batch-ops
关键点：Folder 只用于逻辑归类，不参与环境变量作用域——环境变量是 Collection 级别的，和 Folder 无关。
登录成功后怎么安全传递 token 给其他 Collection
靠手动复制粘贴 accessToken 是最危险的做法：容易过期、易输错、无法审计。Postman 提供的正确路径是「环境变量 + 集合级预请求脚本」，但必须注意作用域和执行顺序。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
常见错误现象：
- 其他 Collection 发请求时 header 里没带 token，控制台报
401 Unauthorized - 登录后 token 显示已写入，但其他请求取出来是
undefined
原因和修复：
- 确保所有业务 Collection 都切换到了同一个环境（右上角环境选择器），而不是各自用默认环境
- 在每个业务 Collection 的
Pre-request Script中添加：pm.request.addHeader("Authorization", "Bearer " + pm.environment.get("accessToken")) - 不要在登录请求的 Tests 脚本里用
pm.collectionVariables.set()——它只对当前 Collection 生效，跨 Collection 不可见 - 如果用了多个环境（如
dev、test），token 必须按环境分别存储，避免 dev token 被误用于 test 环境
为什么登录请求的 Tests 脚本里不能写断言校验 token 格式
很多人会在登录请求的 Tests 里加一段 JS 判断 responseJson.result 是否为 JWT 格式（比如是否含 . 分隔的三段），这看似严谨，实际会造成两个后果：一是掩盖真实失败原因（比如后端返回了 500 但 token 字段为空，断言报错反而盖过了状态码）；二是干扰自动化流程（CI 中 token 失效时，你希望看到明确的 401 或 500，而不是一个模糊的 “token format invalid”）。
更合理的做法：
- Tests 里只做最小必要验证：
pm.response.code === 200、pm.expect(responseJson.code).to.eql("200") - 把 token 解析和字段校验放到后续接口的 Tests 里（比如调用用户信息接口时，再验证返回的
user.id是否匹配 token 中的sub） - 真正需要校验 token 签名或有效期时，用 Postman 的
jwt.decode()辅助函数，但仅限调试，不放进正式测试集
复杂点在于：token 的有效性最终由后端鉴权中间件决定，前端能做的只是确保它存在、非空、结构基本合规——其余交给 HTTP 状态码说话。
