Postman 不直接获取 OAuth 1.0 access token，需手动配置 Consumer Key、Consumer Secret、Token 和 Token Secret 四项密钥；时间戳和随机数默认自动生成，但本地时间不准可能导致签名失败；签名位置（header 或 URL）须严格按 API 文档要求选择；空参数是否参与签名取决于服务端实现，可启用 Add empty params to signature 调试；Token/Token Secret 过期后无法刷新，必须重新授权并手动更新所有变量。
Postman 本身不直接“获取” OAuth 1.0 的 access token，它只负责按规范生成合法签名——你必须提前从服务方拿到 Consumer Key、Consumer Secret、Token 和 Token Secret（如果用的是 3-legged 流程），否则签名必失败。
OAuth 1.0 签名必须填全这 4 个密钥字段
Postman 的 OAuth 1.0 配置界面看着简单，但漏填任意一个都会导致 401 Unauthorized 或 Invalid signature。常见错误是只填了 Consumer Key 和 Consumer Secret，却忽略 Token 和 Token Secret（尤其在已授权用户上下文里）。
-
Consumer Key和Consumer Secret：应用注册时分配的凭证，固定不变 -
Token和Token Secret：用户授权后颁发的临时凭据，每次授权流程不同，不能复用旧值 - 时间戳（
Timestamp）和随机数（Nonce）Postman 默认自动生成，一般不用改；但若服务端校验严格（比如要求Timestamp在 30 秒内），而你的本地时间不准，就得手动同步系统时间
签名位置选错会导致服务端根本收不到认证头
Postman 提供两个签名注入位置：Add params to header 和 Add params to request URL。这不是可选项，而是由 API 文档强制约定的——有些服务（如早期 Twitter API v1.1）只认 header 中的 Authorization 头；有些老系统则只从 query string 解析 OAuth 参数。
Postman 12.27.7 Windows x64 官方安装包，适用于 API 设计、调试、测试与协作。该系列包含 Enterprise 云端性能测试静态 IP 出口能力，以及接口规范标签管理改进，适合受限网络测试与规范资源组织场景。
- 勾选
Add params to header→ 所有 OAuth 参数（包括oauth_signature）塞进Authorization请求头，格式为OAuth realm="", oauth_consumer_key="...", ... - 不勾选 → 参数作为 query 参数拼到 URL 后面（GET）或 form body（POST），此时 header 里不会出现
Authorization字段 - 务必和服务文档对齐；若不确定，先抓包看成功请求是怎么发的，再照着配
空参数是否参与签名，得看服务端实现
OAuth 1.0 规范允许实现方自由决定是否把空值参数（比如 oauth_callback=""）纳入签名基字符串计算。Postman 默认不包含空参数，但如果你遇到 Invalid signature 且确认密钥无误，试试打开 Add empty params to signature。
- 这个开关只影响签名计算，不影响最终发送的参数内容
- 开启后，哪怕你没填
Callback URL，Postman 也会在签名时把它当作oauth_callback=""参与哈希 - 典型踩坑场景：调用某些遗留金融类 API，它们的签名逻辑硬编码了空参数占位
真正麻烦的不是配置界面点几下，而是密钥生命周期管理——Token 和 Token Secret 通常有过期时间，且无法刷新（OAuth 1.0 没 refresh token 概念）。一旦过期，整个集合的请求就全挂，你得重新走授权流程拿新 pair，然后批量替换所有地方的变量值。别指望 Postman 自动续期。
