石器时代 – 手动提交 token
Postman 调试需要鉴权的接口是个很常见的操作，以我业务中常用的 jwt + Authorization Header 的方案为例，通常这种情况下，我们会在 postman 的每一个请求头中，设置 login 后返回的授权 token，携此token来向后端请求数据
铁器时代 – 共享环境变量
同时为了简便和统一，不用在每次调用不同接口的时候，还要将一个相同的 token 复制来复制去，故直接采用设置成 postman 环境变量的方式，这样一来一键切换各种开发环境也方便
仍然嫌手动处理环境变量麻烦
但每次都要先调用登录接口，然后从中复制出 token，再在环境变量的管理页面来粘贴替换新的 token，多少还是感觉有一点点麻烦，我就一直在想是否能像基于session的鉴权后端返回的 set-cookie header一样，请求客户端点完登录后，接下来的操作都会自动带上新的鉴权信息（token / cookie-based-session-id）
机缘巧合之下，发现了接口的 Tests功能
电气时代 – 自动注入
Tests 功能原本主要是为了能在接口完成后调用测试框架来对 api 进行测试的，但因为在这个地方：
- 能访问到接口的返回值
- 能访问及操作 postman 环境变量
故我们完全可以基于这个功能，在登录之后自动读取相关的 token, 然后调用 postman 的 api 将 token 设置回当前环境下的相关环境变量 {{token}}，这样的话下次登录失效，或者要换账户之类的操作，只要再调用一次登录接口，环境里的token就自动替换为最近一次登录的 token 了😁
注：如果不是很清楚如何获取和处理登录接口的返回体，或者不知道postman如何组织我们的api的返回结构，可以用 console.log 打印一下 pm.response 看看结构再进行下一步处理, 左下角可以打开 postman 的控制台